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 _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
