Commits log should tell a story

Having a clear and informative log can serve for many things: finding bugs, the culprit of a change or just for the fun of reading it in an orderly fashion. In order to achieve that clearish log I’m using a handful of extensions, each one of them for a given scenario.

Scenario 1: Automatic merges

If you’re using a distributed version control system, like git or mercurial, sometimes you’ll find that the majority of merges don’t contribute to the story being told, they are just automatic merges messages.

But, instead of merging I use the rebase extension like this: hg pull --rebase and by doing so I’ll have sequential information instead of branches.

Scenario 2: Wip messages

Another common scenario is when I’m in the middle of a feature and a teammate pushes something I need in order to finish it. Here, instead of committing a lame “wip” message, pull and commit again I use the shelve extension. This does the trick of saving my work in progress in a virtual shelve, and then I can:

Scenario 3: Recovering wrong commits

Sometimes I just forget to add some file to a commit or the commit is just plain wrong. What I do here is to use the rollback command to revert my working copy to the exactly same state as if the commit never happened, and then you can add or modify whatever you want and commit correctly.

Scenario 4: Cherry-picking commits

Sometimes when I’m in a middle of a new feature I find a bug, I squish it and keep going. The thing here is what message should I write on my commit, should I mention the fix or not? What about if I could pick the modifications I’ve made and commit several times? That’s when the record extension came in handy. With it you can visualize which diff chunk you want to add to the commit log. This way you can cherry-pick which ones you want to be part of one commit and which parts belong to another one, therefore differentiating the bug fix from the new feature.