[llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 6 19:53:46 PDT 2016
> 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.
More information about the llvm-dev