painful merges

[Richard Eisenberg]

Hi devs,

There are various times when we want to make some change to a large number of lines/files, but the change is very very boring. Two somewhat recent cases that come to mind are de-tabbing and the .lhs -> .hs conversion. These sorts of changes cause painful merges for anyone who is working on a branch. However, this pain is mitigated substantially if two properties hold:

 1) The commit does *nothing* interesting.
 2) The branch-writer knows about the commit in question.

If these two properties hold, then the branch-writer can merge with the commit previous to the painful one, resolve all conflicts, and then merge the painful commit. During the painful merge, the branch-writer can be blissfully carefree about understanding the code -- after all, the painful merge is uninteresting and mechanical. Then, the branch-writer can continuing merging more commits, paying closer attention.

In most cases, it should be easy for us to maintain property (1) going forward. Property (2) is harder, so I propose the following:

** All commits expected to be painful to merge, but are otherwise uninteresting, include "[painful merge]" in the commit message. **

This seems to be a really easy workflow to implement, and it would make, for example, the long, drawn-out debate over detabbing perhaps easier to resolve.

Bikeshedding over the keyword [painful merge] welcome, along with more constructive comments. Is anyone aware of this convention implemented in other projects?

Thanks,
Richard