<div dir="ltr">Have you tried the git-imerge add-on?<div><br></div><div><a href="https://www.youtube.com/watch?v=FMZ2_-Ny_zc">https://www.youtube.com/watch?v=FMZ2_-Ny_zc</a><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 5:17 AM, Robinson, Paul via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
> -----Original Message-----<br>
> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of David<br>
> A. Greene via llvm-dev<br>
> Sent: Thursday, June 02, 2016 7:48 PM<br>
> To: Matthias Braun via llvm-dev<br>
> Subject: Re: [llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?<br>
><br>
> Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:<br>
><br>
> > - Even in the long term I would vote to stay with linear history, I<br>
> > see little benefits in having "correct" origin information of a commit<br>
> > that the merging model provides.<br>
><br>
> We often revert entire feature merges when problem arise.  It's much<br>
> easier to do in a merging workflow because you have a single commit to<br>
> revert.  In the end I don't really care which model LLVM uses.  I just<br>
> want to provide as much working knowledge as I can based on experience<br>
> doing exactly this kind of SVN->git transition.<br>
><br>
> > On the other hand I find merge commits in the history unfriendly to<br>
> > readers (esp. the merges themselfes where you suddenly see conflicts<br>
> > of multiple commits getting resolved),<br>
><br>
> It's certainly true that merge commits make history harder to follow<br>
> with "git log."  I find "git log --oneline --graph --decorate" to be<br>
> pretty useful.<br>
><br>
> > bisection also gets a lot harder with merges in the history as it is<br>
> > hard to decide which branch to follow.<br>
><br>
> I don't understand this statement at all.  git-bisect handles merges<br>
> just fine.  We use a heavily branching/merging model and we've never had<br>
> a problem bisecting.<br>
<br>
</div></div>We have a pile of local changes in our branches, and big merges from the<br>
upstream branch are a huge pain.  If a bisection tries to follow the<br>
upstream branch then we lose all our local changes on that iteration.<br>
Mostly that means the bisection can't identify where the problem began<br>
(or ended) within the big merge-from-upstream; all we know is that it<br>
happened somewhere within the big merge.<br>
<br>
We are trying to change our processes to make merges from upstream as<br>
small as possible, ideally single commits, but this is a disruptive<br>
change and not one that everybody can manage.<br>
--paulr<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>