[cfe-dev] [llvm-dev] "Living Downstream Without Drowning" BOF @ Dev Meeting

[David Chisnall via cfe-dev]

On 19 Oct 2015, at 19:05, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I find the git imerge script extremely useful for this kind of situation.
> 
> https://github.com/mhagger/git-imerge
> 
> Logically, it does something similar to rebasing your local branch onto EVERY commit in the upstream branch, in turn, until it finds conflicts. There is cleverness to make this efficient, let you stop and restart the merge, share intermediate state with others, build&test intermediate results (automatically if you want). At the end of the process you can choose to keep the intermediate commits that are the same as the result of a "git merge" or a "git rebase" or a new feature the author calls "rebase with history" that keeps the original branch too and makes each rebased commit have the corresponding commit in the original branch as a parent.

Thank you very much for the recommendation!  The down side of git-imerge is that it is O(NM), where N is the number of your commits since the last merge and M is the number of upstream commits.  I just finished a merge of about 6 months with 4000 upstream commits and a bit over 100 local ones - it took about a week of CPU time.  The huge up side is that it took a lot less human time than previous merges.

The only irritation is that LLVM has a strong policy of reverting stuff that’s broken.  The Tuples work was committed and reverted three times in quick succession.  Each time introduced merge conflicts, though by the third time I’d had to fix them, I was getting pretty good at it.  I don’t wish to change the policy with regard to reverts (having a working and stable head is very valuable), but it would be good if we could have a stronger policy that stuff that is reverted goes into Phabricator and is not recommitted until the person who initially reverted it has signed off (or, at least, there’s a strong consensus that it’s the right thing).

The main lesson for me is that more frequent merges will be less painful.  That’s a big change, because previously I’d spend a day or two fixing merge conflicts no matter how frequently or infrequently I merged, so the incentive was to merge every 3-6 months.

David