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

[Alex Bradbury via cfe-dev]

On 5 November 2015 at 09:18, David Chisnall via cfe-dev
<cfe-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).

It seems many causes of the commit->revert->commit->revert->... cycle
are unexpected buildbot failures. The ability to submit changesets
from phabricator to test by the buildbots (which as I understand it,
isn't currently available) would reduce the frequency of this
ping-ponging. That said, it happens fairly rarely and the current
approach seems to work just fine, other than the minor annoyance David
notes.

Alex