[llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?

[Bruce Hoult via llvm-dev]

Have you tried the git-imerge add-on?

https://www.youtube.com/watch?v=FMZ2_-Ny_zc


On Tue, Jun 7, 2016 at 5:17 AM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> > -----Original Message-----
> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> David
> > A. Greene via llvm-dev
> > Sent: Thursday, June 02, 2016 7:48 PM
> > To: Matthias Braun via llvm-dev
> > Subject: Re: [llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?
> >
> > Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >
> > > - Even in the long term I would vote to stay with linear history, I
> > > see little benefits in having "correct" origin information of a commit
> > > that the merging model provides.
> >
> > We often revert entire feature merges when problem arise.  It's much
> > easier to do in a merging workflow because you have a single commit to
> > revert.  In the end I don't really care which model LLVM uses.  I just
> > want to provide as much working knowledge as I can based on experience
> > doing exactly this kind of SVN->git transition.
> >
> > > On the other hand I find merge commits in the history unfriendly to
> > > readers (esp. the merges themselfes where you suddenly see conflicts
> > > of multiple commits getting resolved),
> >
> > It's certainly true that merge commits make history harder to follow
> > with "git log."  I find "git log --oneline --graph --decorate" to be
> > pretty useful.
> >
> > > bisection also gets a lot harder with merges in the history as it is
> > > hard to decide which branch to follow.
> >
> > I don't understand this statement at all.  git-bisect handles merges
> > just fine.  We use a heavily branching/merging model and we've never had
> > a problem bisecting.
>
> We have a pile of local changes in our branches, and big merges from the
> upstream branch are a huge pain.  If a bisection tries to follow the
> upstream branch then we lose all our local changes on that iteration.
> Mostly that means the bisection can't identify where the problem began
> (or ended) within the big merge-from-upstream; all we know is that it
> happened somewhere within the big merge.
>
> We are trying to change our processes to make merges from upstream as
> small as possible, ideally single commits, but this is a disruptive
> change and not one that everybody can manage.
> --paulr
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160607/78524fdc/attachment.html>