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

[Matthias Braun via llvm-dev]

> On Nov 5, 2015, at 1:18 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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).
If you are using git: I had good experiences with "git config rerere.enabled true" which builds a database on how conflicts are resolved and will look those up for you when you encounter the same conflict a 2nd time.

- Matthias