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

[Bruce Hoult via llvm-dev]

According to the author of git imerge, rerere interacts badly with it, so
he temporarily turns it off.

Half the point of git imerge is that you don't *have * *to* solve the same
conflicts repeatedly. And you don't. Unless that commit has been backed out
and reapplied multiple times. Which sould be very much the exception.

The other half of the point of git imerge is that you solve the minimum
possible conflict, that of exactly one trunk commit against one branch
commit. This is in general vastly easier than trying to decipher how your
branch commit conflicts with the entire history of changes to master.

On Thu, Nov 5, 2015 at 9:04 PM, Matthias Braun <mbraun at apple.com> wrote:

>
> > 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
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151105/66bfd6ae/attachment.html>