Use git-subrepo for the tools/ directory #1466
Conversation
subrepo: subdir: "tools" merged: "518ce0f23c" upstream: origin: "tools-origin" branch: "mongo-c-tools" commit: "none" git-subrepo: version: "0.4.6" origin: "https://github.com/ingydotnet/git-subrepo" commit: "110b9eb"
subrepo: subdir: "tools" merged: "7f8ff8e0a2" upstream: origin: "tools-origin" branch: "mongo-c-tools" commit: "7f8ff8e0a2" git-subrepo: version: "0.4.6" origin: "https://github.com/ingydotnet/git-subrepo" commit: "110b9eb"
| ensure that you have a `tools-origin` set to the proper URL. Unless you "know | ||
| what you are doing", you will want to use the upstream `mongo-c-driver` | ||
| repository as the remote: |
There was a problem hiding this comment.
For rationale documentation purposes, why mongodb/mongo-c-driver as the remote rather than a separate mongodb(-labs)/mongo-c-driver-tools repo (a la mongodb-labs/drivers-evergreen-tools)? I find the use of the "disjoint branch" to be strange. It is effectively already behaving as a separate git repo that is using an arbitrary commit as a common ancestor with the main branch. If we want to use the "disjoint branch" method, might as well go all-in and remove the common ancestor entirely (we won't ever be merging the mongo-c-tools branch itself into the main branch anyways, right?).
There was a problem hiding this comment.
No reason at all other than "I didn't bother to create a new repo for it" :). At $prior_job we used a separate repo for the subrepo target, and it works great with that. It'd probably actually be better, since there wouldn't be need to juggle the remote URL.
There was a problem hiding this comment.
Oh also I don't have the permission to create a new repo in the org, so I just used what I had available.
There was a problem hiding this comment.
We already have a project at 10gen/mongo-c-driver-tools.git which might be a good candidate, assuming that a project which isn't public is acceptable in this case.
There was a problem hiding this comment.
That could very well work. It does not need to be a publicly accessible repo.
There was a problem hiding this comment.
I support use of 10gen/mongo-c-driver-tools. AFAIK the only actively used script in the repo is release.py.
| which contains only the history of this directory as the root. | ||
|
|
||
| **NOTE** that doing a `git subrepo push` will send changes into the remote | ||
| branch immediately without a PR! See below about how to push changes. |
There was a problem hiding this comment.
If that's the case, we might consider marking that branch as protected (whether it moves to a distinct project or not).
| ensure that you have a `tools-origin` set to the proper URL. Unless you "know | ||
| what you are doing", you will want to use the upstream `mongo-c-driver` | ||
| repository as the remote: |
There was a problem hiding this comment.
We already have a project at 10gen/mongo-c-driver-tools.git which might be a good candidate, assuming that a project which isn't public is acceptable in this case.
| conflicts. | ||
|
|
||
| To modify the contents of this directory, simply update and commit them as one | ||
| would do normally. If you want your changes to undergo review: |
There was a problem hiding this comment.
A pattern I find helpful when updating drivers-evergreen-tools is to test the changes in a driver by cloning the updated branch. Example: mongodb-labs/drivers-evergreen-tools#359 was tested in the C driver with an Evergreen patch of the C driver with temporary changes to clone the branch in review:
git clone --depth=1 [email protected]:kevinAlbs/drivers-evergreen-tools.git --branch pykmip_failure
If mongo-c-driver-tools is used, consider adding instructions for testing changes in review in the C driver, C++ driver, and/or libmongocrypt. Something like the following:
To test changes in review, scripts may be updated from a separate remote branch with:
`git subrepo pull --remote [email protected]:$user/mongo-c-driver-tools.git --branch $branch_in_review $this_subdir`| ensure that you have a `tools-origin` set to the proper URL. Unless you "know | ||
| what you are doing", you will want to use the upstream `mongo-c-driver` | ||
| repository as the remote: |
There was a problem hiding this comment.
I support use of 10gen/mongo-c-driver-tools. AFAIK the only actively used script in the repo is release.py.
These changes are just an "maybe something interesting to pursue", and not a finalized proposal. This should help us consolidate scripts (CMake, shell, Python, etc.) between libmongocrypt, mongocxx, and mongoc without manually copy-pasting changes.
See
README.mdfor details