Keep the history clean
Simplify your history, in the most intuitive and clutter-free way to combine commits from multiple developers in a shared branch.
1.1. Rebase
Workflow using the Rebase Extension.
Suppose you have a history like this: hg log -G
@ changeset: 2:81b92083cb1d | tag: tip | summary: my new feature: edit file a | o changeset: 1:8bdc4508ac7b | summary: my new feature: add file b | o changeset: 0:d554afd54164 summary: initial
This means, revision 0 is the base on which you started to work on your feature. Now you want to have revisions 1-2 on a named branch, let's say my-feature. Update to revision 0 and create that branch:
$ hg up 0 $ hg branch my-feature $ hg ci -m "start new branch my-feature"
The history now looks like this:
@ changeset: 3:b5939750b911 | branch: my-feature | tag: tip | parent: 0:d554afd54164 | summary: start new branch my-feature | | o changeset: 2:81b92083cb1d | | summary: my new feature: edit file a | | | o changeset: 1:8bdc4508ac7b |/ summary: my new feature: add file b | o changeset: 0:d554afd54164 summary: initial
Use the rebase command to move revisions 1-2 onto revision 3:
$ hg rebase -s 1 -d 3
This results in the following graph:
@ changeset: 3:88a90f9bbde7 | branch: my-feature | tag: tip | summary: my new feature: edit file a | o changeset: 2:38f5adf2cf4b | branch: my-feature | summary: my new feature: add file b | o changeset: 1:b5939750b911 | branch: my-feature | summary: start new branch my-feature | o changeset: 0:d554afd54164 summary: initial
That's it .. moving around already pushed changesets generally is a bad idea, unless you work in a small team where you are able to communicate and enforce your history manipulation.
1.2. Mercurial Queues
Workflow using the MqExtension. Let's say the changesets to move are revisions 1-3:
hg qimport -r 1:3 # convert revisions to patches hg qpop -a # remove all them from history hg branch new # start a new branch hg qpush -a # push them all back into history hg qfin -a # finalize the patches
Mq can only convert consecutive changesets from a head. It turns normally immutable changesets into mutable patches that can be edited.
Don't edit changesets that have been pushed. Mq changes the hashes so they will be effectively new changesets. Only edit history that hasn't been pushed.
Suppose you have a history like this: hg log -G
#default branch @ changeset: 3:cb292fcdbde1 | o changeset: 2:e746dceba503 | o changeset: 1:2d50c7ab6b8f | o changeset: 0:c22be856358b
and we want
@ changeset: 3:0e85ae268e35 | branch: feature/my_feature | o changeset: 2:1450cb9ec349 | branch: feature/my_feature | o changeset: 1:7b9836f25f28 | branch: feature/my_feature | / | o changeset: 0:c22be856358b
hg export -o feature.diff 1 2 3 hg update 0 hg branch feature/my_feature hg import feature.diff
Here is the state of your local repository
@ changeset: 6:0e85ae268e35 | branch: feature/my_feature | o changeset: 5:1450cb9ec349 | branch: feature/my_feature | o changeset: 4:7b9836f25f28 | branch: feature/my_feature | | o changeset: 3:cb292fcdbde1 | | | o changeset: 2:e746dceba503 | | | o changeset: 1:2d50c7ab6b8f |/ | o changeset: 0:c22be856358b
Now you need to delete the revisions 1 2 and 3 from your default branch. You can do this with strip command from mq's extension. hg strip removes the changeset and all its descendants from the repository.
And now strip this repository on revision 1.
hg strip 1
now we got
@ changeset: 3:0e85ae268e35 | branch: feature/my_feature | o changeset: 2:1450cb9ec349 | branch: feature/my_feature | o changeset: 1:7b9836f25f28 | branch: feature/my_feature | o changeset: 0:c22be856358b
note: changesets are different but revisions are the same
1.3. Conclusion
When multiple developers work on a shared branch, pull & rebase your outgoing commits to keep history cleaner