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

[Mehdi Amini via llvm-dev]

> On Jun 6, 2016, at 7:17 PM, 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.

I had this exact problem (merge that pulled a large number of commits), and the way I tackled it was: 1) bisect at "coarse" granularity (i.e. between the merges) and 2) when I figure which merge is problematic I had a script that will branch, get all the upstream commits between the two merges, and merge them individually in this new branch. Then I repeated the bisect in this branch and got the exact commit that introduced the regression.

-- 
Mehdi