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

[Robinson, Paul via llvm-dev]

> -----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