Skip to content
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

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions tools/.gitrepo
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
90 changes: 90 additions & 0 deletions tools/README.md
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:
Comment on lines +31 to +33
Copy link
Collaborator

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 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?).

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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 is release.py.


```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.
Copy link
Collaborator

Choose a reason for hiding this comment

The 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:
Copy link
Collaborator

Choose a reason for hiding this comment

The 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:

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`


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).