Changes to commit workflow
[This is an experiment in publishing a doc piece by piece as blog entries. Please refer to the main page for additional context.]
With all the changes to support git, how will that affect a committer’s workflow? (For developer impact, see this post.)
The primary goal is to work within the existing Mozilla commit policy [1]. Working within that constraint, the idea is “as little as possible”, and this post will try to describe how big “as little” is.
Remember: all existing ways of working with hg will continue to work! These are just going to be some additional options for folks who prefer to use github & bitbucket.
Introduction
To start things off, here are the simplified workflows that describe how things currently work with the Mercurial repositories on hg.m.o and following commit policy. The major differences between the committer’s workflow and the developer’s workflow are:
- the source of the changes (could be patches from developers without commit access, in addition to development work done directly by the committer).
- the ultimate destination repository is the repository of record hosted on hg.mozilla.org.
The following table should match today’s workflow for landing someone else’s (or their own) approved patch:
| Committer Action | Steps Involved | Pseudo Commands |
|---|---|---|
| First time checkout [2] | ||
| get personal copy | ||
| get copy on PC | hg clone hg.m.o PC | |
| tweak for 1 step commit to hg | add hg.m.o as pushable path | |
| Work Cycle | ||
| update local repo to tip | hg pull –update | |
| incorporate r+ work [3] | hg patch OR pull from github or bitbucket (may not match r+ attachment) [4] | |
| resolve conflicts | ||
| local work | hg commit | |
| Commit Process | ||
| hg push hg.m.o |
Changes for Bitbucket
As bitbucket uses mercurial as it’s primary DVCS, you might expect there to be not too many changes. That’s correct - there is just some additional steps on bitbucket so other users can see your work.
The changes from hg.m.o are italicized.
| Committer Action | Steps Involved | Pseudo Commands |
|---|---|---|
| First time checkout [2] | ||
| get personal copy | bitbucket fork | |
| get copy on PC | hg clone bitbucket PC | |
| tweak for 1 step commit to hg | add hg.m.o as pushable path | |
| Work Cycle | ||
| update local repo to tip | hg pull –update | |
| incorporate r+ work [3] | hg patch OR pull from github or bitbucket (may not match r+ attachment) [4] | |
| resolve conflicts | ||
| local work | hg commit | |
| Commit Process | ||
| hg push hg.m.o |
Changes for Github
For github, there are a few additional steps that will be supported by scripts. As above, the differences from hg.m.o are italicized.
| Committer Action | Steps Involved | Pseudo Commands |
|---|---|---|
| First time checkout [2] | ||
| get personal copy | github fork | |
| get copy on PC | git clone github PC | |
| tweak for 1 step commit to hg | run script to setup hg repo & git post commit hooks & magic_refs [5] | |
| Work Cycle | ||
| update local repo to tip | git pull | |
| incorporate r+ work [3] | apply patch manually OR pull from github or bitbucket (but may not match r+ attachment) [4] | |
| resolve conflicts | ||
| local work | git commit | |
| Commit Process | ||
| git push magic_ref [5] |
Notes
| [1] | There is a strong case to be made for revising the commit policy to account for both new tooling (e.g. github/bitbucket) and new Mozilla projects (e.g. everything beyond Firefox/Thunderbird). A policy discussion involves a lot more groups, and is explicitly out of scope of this effort. |
| [2] | (1, 2, 3) assumes committer keeps “clean repo” for all push to moz actions (best practice) |
| [3] | (1, 2, 3) due to patch rot, the committer may need to make adjustments to the patch. It’s up to the authorized committer to decide if such changes require re-approval. |
| [4] | (1, 2, 3) directly incorporating a pull request (from either github, bitbucket, or any other hosting service) is straightforward with the hg-git extension installed in Mercurial, if the other repo was based on the same original. This requires coordination among the team members. |
| [5] | (1, 2) This is how several developers now work, what’s new is the wrapper script to make it easy to setup. See the reference section of the main project page for links to their original code (which will be the basis for this project). |
Change Log
2012-03-21 Added step of bring local repository up to date prior to incorporating changes.