eir at cis.upenn.edu
Sun Dec 7 18:59:36 UTC 2014
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?
More information about the ghc-devs