llvm dev - Jun 2016 - [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.
> - As for squashing: I don't see why people would enforce that on the
> server. Often developers went through the trouble of forming a nice
> series of independent patches that helps understanding the changes. To
> people just appending fixup commits like mentioned below I'd strongly
> advice them to learn about "git rebase -i" so they can squash on
their
> local checkout as necessary before committing to the server!
I generally agree with this.  The main problem that arises is someone
needing to do a fixup commit on a branch that someone else has accessed.
Then it's a history rewrite for the other person and that gets ugly.  I
don't anticipate this kind of local branch sharing to happen freqently,
at least not among people who are uncomfortable with git.  git experts
will know what to do with the situation.

                               -David

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

> 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

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>