-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use git-subrepo for the tools/ directory #1466
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
; DO NOT EDIT (unless you know what you are doing) | ||
; | ||
; This subdirectory is a git "subrepo", and this file is maintained by the | ||
; git-subrepo command. See https://github.com/ingydotnet/git-subrepo#readme | ||
; | ||
[subrepo] | ||
remote = tools-origin | ||
branch = mongo-c-tools | ||
commit = 7f8ff8e0a2f7f2639745c5b48ac1f9e10c0518fd | ||
method = merge | ||
cmdver = 0.4.6 | ||
parent = 291608fd93e57aed366c2483feb568f3f81c27a7 |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
# `mongo-c-tools` | ||
|
||
This directory contains shared scripts and tools for native C and C++ | ||
development. | ||
|
||
|
||
## As a Subrepo | ||
|
||
If this directory contains a `.gitrepo` file, then this directory is being | ||
tracked as a *subrepo* of some parent repository. If this file does not exist | ||
but a `.git/` directory *does* exist, then you are looking at the tools | ||
repository itself. | ||
|
||
[`git subrepo`](https://github.com/ingydotnet/git-subrepo) is a set of scripts | ||
and conventions for pushing/pulling/syncing changes in a subdirectory between | ||
different repositories with full history tracking. *Using* the contents of this | ||
directory does not require the `git subrepo` tool, but pushing and pulling | ||
changes in this subrepo directory will require `git subrepo` (or knowing | ||
the appropriate commands to execute for the same effect). | ||
|
||
If you are simply using these scripts, you do not have to deal with the subrepo | ||
commands. If you wish to modify/sync these scripts, read on below. | ||
|
||
|
||
### Preparing | ||
|
||
`git-subrepo` tracks a subrepo directory using a remote+branch pair as the | ||
"source of truth" for the subrepo contents. The remote+branch pair is fixed in | ||
the `.gitrepo` file. In this subrepo directory, the `remote` is not set to a | ||
URL, but to a name `tools-origin`. In order to push/pull, you will need to | ||
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: | ||
|
||
```sh | ||
$ git remote add tools-origin "[email protected]:mongodb/mongo-c-driver.git" | ||
``` | ||
|
||
The content of this subrepo is contained by the disjoint branch `mongo-c-tools`, | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If that's the case, we might consider marking that branch as protected (whether it moves to a distinct project or not). |
||
|
||
|
||
### Pulling Changes | ||
|
||
If the remote copy of the subrepo has been updated (e.g. as part of another | ||
project's changes), then the local copy of this subrepo can be updated by using | ||
`git subrepo pull`: | ||
|
||
```sh | ||
$ git subrepo pull $this_subdir | ||
``` | ||
|
||
**Note:** | ||
|
||
- Doing a `subrepo pull` requires that there be *no* unstaged changes in the | ||
parent repository. | ||
- Pulling a subrepo will create a new commit on the current branch. This commit | ||
contains the changes that were pulled from the remote, as well as an update to | ||
the `.gitrepo` file. | ||
- If merge conflicts occur, you will find yourself in a copy of the disjoint | ||
branch in order to perform a conflict resolution. Follow the instructions | ||
from `git-subrepo` to handle the merge. | ||
|
||
|
||
### Modifying these Files | ||
|
||
Before modifying the contents of this directory, be sure that you have the | ||
latest changes from the remote branch according to the | ||
[*pulling changes*](#pulling-changes) section. This will avoid annoying merge | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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:
If 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` |
||
|
||
1. Create a PR and go through code review as normal. Don't worry about the | ||
subrepo at this step. | ||
2. Merge the PR as normal. | ||
3. Begin a new temporary branch `$tmp` for the subrepo update that points to the | ||
merge commit that resulted from the PR merge. | ||
4. With the `$tmp` branch active, run `git subrepo push`. This will create a new | ||
commit on `$tmp` and send the local changes into the remote. | ||
5. Run `git subrepo status` and verify that the `Pull Parent` of the subrepo | ||
refers to the merge commit from the orginal PR. | ||
6. Merge the `$tmp` back into the base branch, either through a PR or by just | ||
pushing it directly without a PR (the `git subrepo push` will only generate a | ||
few lines of change in the `.gitrepo` file and won't be interesting to | ||
review). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For rationale documentation purposes, why
mongodb/mongo-c-driver
as the remote rather than a separatemongodb(-labs)/mongo-c-driver-tools
repo (a lamongodb-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 themongo-c-tools
branch itself into the main branch anyways, right?).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could very well work. It does not need to be a publicly accessible repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I support use of
10gen/mongo-c-driver-tools
. AFAIK the only actively used script in the repo isrelease.py
.