This is why you use git

I wanted distributed version control before their was distributed version control.  When it finally became practical, I looked at the options, and chose Mercurial – because murcurial clearly works like a distributed version control system ought to, while git was… lets say idiosyncratic (because ‘weird looking’ would be rude)

Recently (when we open sourced XenServer) I found myself having to get to grips with git and github.  Over the last year or two I’ve begun to understand why git turns out to be better in many respects for real world version control usecases (except for managing patch queues on Windows – hg still wins there)

Today gave me an example of ‘one of those times’…

My problem was:

I had submitted a patch to a public repository – but it turned out to have problems, and for reasons of time constraints I had to revert it.  Since this was all done in github, I used the very handy github revert feature.  The github repository then progressed somewhat without me.

Meanwhile, i fixed the problems in a local private repo.  Which didn’t pull in the revert from upstream.  So I ended up with branches looking like

Upstream: —–Patch A—-Changes—-Revert Patch A—-More Changes

Local:         —–Patch A—-Fixes for Patch A—-More fixes for Patch A

What I wanted to submit to upstream was Patch A again, with all fixes, rebased to work on top of the existing upstream… all as one big patch

How I managed this was:

Clone the upstream branch into my personal github repository

create a pull request against my clones upstream branch which reverted ‘Revert Patch A’ – and merge it.  Giving

Personal Upstream : —–Patch A—-Changes—-Revert Patch A—-More Changes——-Revert “Revert Patch A”

I then fetched this into my local git repo

I rebased my previous local branch against this branch, leaving me with a branch containing

—–Patch A—-Changes—-Revert Patch A—-More Changes——-Revert “Revert Patch A” —–Fixes for Patch A—-More fixes for Patch A

And finally another interactive rebase let me squash things down to

—–Patch A—-Changes—-Revert Patch A—-More Changes——-Patch A (2nd attempt)


This was then sent back up to github so I could issue a pull request to merge to upstream.


This certainly isn’t a workflow you would see in a non-distributed vcs – but it also isn’t the sort of workflow you would expect to see with mercurial (which has more of a policy of not changing history – rather than trusting you and giving you the tools to perform patch management)

You must be logged in to post a comment.