reject merges on gdb release branches?

reject merges on gdb release branches?

[Joel Brobecker]

We are already rejecting merge commits on branch master.

I propose we do the same for the gdb-7.7 branch, and generally
speaking on all GDB release branches, just to make sure that
people don't accidently push a merge when they meant to cherry-pick.
Thoughts?

At the moment, it appears that this can only be done by adding
a "BRANCH_NAME = true" line in the repository's config file.
I can do that.

-- 
Joel

Re: reject merges on gdb release branches?

[Doug Evans]

On Tue, Jan 21, 2014 at 9:11 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> We are already rejecting merge commits on branch master.
>
> I propose we do the same for the gdb-7.7 branch, and generally
> speaking on all GDB release branches, just to make sure that
> people don't accidently push a merge when they meant to cherry-pick.
> Thoughts?
>
> At the moment, it appears that this can only be done by adding
> a "BRANCH_NAME = true" line in the repository's config file.
> I can do that.

I like this idea.

Re: reject merges on gdb release branches?

[Yao Qi]

On 01/22/2014 01:11 PM, Joel Brobecker wrote:
> I propose we do the same for the gdb-7.7 branch, and generally
> speaking on all GDB release branches, just to make sure that
> people don't accidently push a merge when they meant to cherry-pick.
> Thoughts?

Joel,
My git knowledge is too poor to understand this.  How does people push
a merge?  My workflow is to cherry-pick approved patches from one branch
to master, and git push.  I thought that is the only way to push
commits to master.  Am I missing something?

-- 
Yao (齐尧)

Re: reject merges on gdb release branches?

[Joel Brobecker]

> > I propose we do the same for the gdb-7.7 branch, and generally
> > speaking on all GDB release branches, just to make sure that
> > people don't accidently push a merge when they meant to cherry-pick.
> > Thoughts?
> 
> My git knowledge is too poor to understand this.  How does people push
> a merge?  My workflow is to cherry-pick approved patches from one branch
> to master, and git push.  I thought that is the only way to push
> commits to master.  Am I missing something?

You are doing thing correctly. Another way to do things, if you have
a large number of commits to push, is to "git rebase your-branch master;
git checkout master; git merge your-branch", which should result in
a "fast-forward merge" (which is actually not technically a merge).
For more info, I really recommend you read a book such as "Pro Git",
as understanding the models behind git is a worthwhile investment.

The purpose of this proposal is to make sure that people don't do
"git merge my-commit-on-master" and push that to the release branch.
This would have catastrophic consequences, as it would bring into
the branch all commits on master since we created the release branch.
Not what the contributor wanted, but very easy to do if you don't
know git well enough.

-- 
Joel

Re: reject merges on gdb release branches?

[Pedro Alves]

On 01/22/2014 05:11 AM, Joel Brobecker wrote:
> We are already rejecting merge commits on branch master.
> 
> I propose we do the same for the gdb-7.7 branch, and generally
> speaking on all GDB release branches, just to make sure that
> people don't accidently push a merge when they meant to cherry-pick.
> Thoughts?

+1.

-- 
Pedro Alves

Re: reject merges on gdb release branches?

[Yao Qi]

On 01/22/2014 03:37 PM, Joel Brobecker wrote:
> You are doing thing correctly. Another way to do things, if you have
> a large number of commits to push, is to "git rebase your-branch master;
> git checkout master; git merge your-branch", which should result in
> a "fast-forward merge" (which is actually not technically a merge).
> For more info, I really recommend you read a book such as "Pro Git",
> as understanding the models behind git is a worthwhile investment.

Thanks for the explanation.

> 
> The purpose of this proposal is to make sure that people don't do
> "git merge my-commit-on-master" and push that to the release branch.
> This would have catastrophic consequences, as it would bring into
> the branch all commits on master since we created the release branch.
> Not what the contributor wanted, but very easy to do if you don't
> know git well enough.

That is true.

-- 
Yao (齐尧)

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Wed, 22 Jan 2014 09:11:33 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> We are already rejecting merge commits on branch master.

Doesn't that mean you are forcing everybody to rebase before
committing from feature branches?  If so, that sounds drastic, and
should have very good reasons.  (Apologies if this was already
discussed and decided, but in that case I'd appreciate a pointer.)

Re: reject merges on gdb release branches?

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> We are already rejecting merge commits on branch master.
Joel> I propose we do the same for the gdb-7.7 branch, and generally
Joel> speaking on all GDB release branches, just to make sure that
Joel> people don't accidently push a merge when they meant to cherry-pick.
Joel> Thoughts?

Yes, it's a good idea.

Tom

Re: reject merges on gdb release branches?

[Joel Brobecker]

> Doesn't that mean you are forcing everybody to rebase before
> committing from feature branches?  If so, that sounds drastic, and
> should have very good reasons.  (Apologies if this was already
> discussed and decided, but in that case I'd appreciate a pointer.)

IIUC, you're asking a general question: Is it OK to do a merge of
a feature branch onto another, and then push that branch?

The currently situation, as discussed during the transition to git,
was that this is not allowed for the "master" branch. Note that
a rebase, compared to a merge, is not that much more work, and has
the nice property of keeping the history linear. I've been managing
patch series of 20+ patches, with regular rebases, without problems.
It's something you do anyway in order to submit the patches, so
I don't think this is an issue in practice.

This proposal is to extend this restriction to all GDB release branches,
for the reasons detailed in my reply to Yao. Basically, this is to
avoid mistakes resulting us in merging more than what you intended.

-- 
Joel

Re: reject merges on gdb release branches?

[H.J. Lu]

On Wed, Jan 22, 2014 at 8:15 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Doesn't that mean you are forcing everybody to rebase before
>> committing from feature branches?  If so, that sounds drastic, and
>> should have very good reasons.  (Apologies if this was already
>> discussed and decided, but in that case I'd appreciate a pointer.)
>
> IIUC, you're asking a general question: Is it OK to do a merge of
> a feature branch onto another, and then push that branch?
>
> The currently situation, as discussed during the transition to git,
> was that this is not allowed for the "master" branch. Note that
> a rebase, compared to a merge, is not that much more work, and has
> the nice property of keeping the history linear. I've been managing
> patch series of 20+ patches, with regular rebases, without problems.
> It's something you do anyway in order to submit the patches, so
> I don't think this is an issue in practice.
>
> This proposal is to extend this restriction to all GDB release branches,
> for the reasons detailed in my reply to Yao. Basically, this is to
> avoid mistakes resulting us in merging more than what you intended.
>

Add binutils mailing list.

I think it is a good idea and it should be extended to all binutils
release branches.

Thanks for doing this.

-- 
H.J.

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Wed, 22 Jan 2014 20:15:20 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > Doesn't that mean you are forcing everybody to rebase before
> > committing from feature branches?  If so, that sounds drastic, and
> > should have very good reasons.  (Apologies if this was already
> > discussed and decided, but in that case I'd appreciate a pointer.)
> 
> IIUC, you're asking a general question: Is it OK to do a merge of
> a feature branch onto another, and then push that branch?

No, I'm asking specifically about the master branch of the GDB
repository.  (I understand the reasoning behind disallowing that for
the release branch, given the practice that bugfixes get applied to
master first.)

> The currently situation, as discussed during the transition to git,
> was that this is not allowed for the "master" branch.

Where was that discussed, and what were the reasons?

> Note that a rebase, compared to a merge, is not that much more work,
> and has the nice property of keeping the history linear.

Rebasing loses information (e.g., if I merged from master several
times during my work).  And I don't really see the downsides of
merging to master.  I also don't object if others want to rebase, I
just don't understand why force everybody to do that.

> It's something you do anyway in order to submit the patches

??? Why would I need to do that for submittal?  Git is perfectly
capable of diffing against any revision of any branch, right?

> This proposal is to extend this restriction to all GDB release branches,

I have nothing against that, I just didn't know about a similar
restriction for master, and was unpleasantly surprised.

Re: reject merges on gdb release branches?

[Joel Brobecker]

> At the moment, it appears that this can only be done by adding
> a "BRANCH_NAME = true" line in the repository's config file.
> I can do that.

OK, given the positive feedback, this has now been done.

-- 
Joel

Re: reject merges on gdb release branches?

[Ricard Wanderlof]

On Wed, 22 Jan 2014, Eli Zaretskii wrote:

>> Note that a rebase, compared to a merge, is not that much more work,
>> and has the nice property of keeping the history linear.
>
> Rebasing loses information (e.g., if I merged from master several
> times during my work).  And I don't really see the downsides of
> merging to master.

I think it's not the merging per se that is a problem, only if it is done 
incorrectly, i.e. merging from a branch that was was broken off from 
master a long time ago, which brings in a lot of unwanted stuff. 
Unfortunately it is all too easy to do that by mistake, especially if one 
doesn't use git on a regular basis.

Loosing information about merges from master during a rebase I don't think 
is too much of an issue. Once the branch has been rebased to master, any 
merges from master would have occurred in the past anyway.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: reject merges on gdb release branches?

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> At the moment, it appears that this can only be done by adding
>> a "BRANCH_NAME = true" line in the repository's config file.
>> I can do that.

Joel> OK, given the positive feedback, this has now been done.

The syntax was slightly off; I got an error from a push.  When I
corrected it I learned that git doesn't allow "." in the name of a
config variable.  So, if we want to do this we'll have to modify the
"update" script directly; either by adding the branch names there or by
changing the config variable syntax.  I don't have time to do this right
now, sorry.  In the meantime I've reverted to the status quo ante,
seeing no other choice.

Tom

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Thu, 23 Jan 2014 08:46:32 +0100
> From: Ricard Wanderlof <ricard.wanderlof@axis.com>
> CC: Joel Brobecker <brobecker@adacore.com>, "gdb-patches@sourceware.org"
> 	<gdb-patches@sourceware.org>
> 
> I think it's not the merging per se that is a problem, only if it is done 
> incorrectly, i.e. merging from a branch that was was broken off from 
> master a long time ago, which brings in a lot of unwanted stuff. 

There's any number of ways one can make a mistake and screw up master.
That cannot be the reason for forcing a particular workflow on
everyone, certainly not before any such problems actually happened
even once.

And I don't understand your fear of unwanted stuff from a divergent
branch: what exactly is special about this situation?  Surely,
examining the diffs before committing and pushing would show what is
about to land on master, so where's the danger that doesn't exist in
any other commit?

> Loosing information about merges from master during a rebase I don't think 
> is too much of an issue. Once the branch has been rebased to master, any 
> merges from master would have occurred in the past anyway.

The information lost can be important when bisecting later, or more
generally researching how a given piece of code or bug entered the
code base.  It can also be important if I merge between my local
branches as part of working on a feature, something that isn't unheard
of.

Again, I can understand that some people are accustomed to rebasing,
and I'm okay with that.  But I don't understand why something that is
essentially a matter of personal preferences is forced on everyone.

Re: reject merges on gdb release branches?

[Joel Brobecker]

> The syntax was slightly off; I got an error from a push.  When I
> corrected it I learned that git doesn't allow "." in the name of a
> config variable.  So, if we want to do this we'll have to modify the
> "update" script directly; either by adding the branch names there or by
> changing the config variable syntax.  I don't have time to do this right
> now, sorry.  In the meantime I've reverted to the status quo ante,
> seeing no other choice.

Thanks for taking of this.

At AdaCore, we use a comma-separated list of regular expressions
to match the branches for which a features should not be applied.
Perhaps we could do the same? I don't have much time right now
either, so status quo ante it is.

-- 
Joel

Re: reject merges on gdb release branches?

[Tom Tromey]

Joel> At AdaCore, we use a comma-separated list of regular expressions
Joel> to match the branches for which a features should not be applied.
Joel> Perhaps we could do the same? I don't have much time right now
Joel> either, so status quo ante it is.

The syntax is just determined by the update hook script.
So I think we'd need a different script.
We have modest needs so it maybe isn't too hard to find an appropriate one.
I can't do it now.

Tom

Re: reject merges on gdb release branches?

[Ricard Wanderlof]

On Thu, 23 Jan 2014, Eli Zaretskii wrote:

>>
>> I think it's not the merging per se that is a problem, only if it is done
>> incorrectly, i.e. merging from a branch that was was broken off from
>> master a long time ago, which brings in a lot of unwanted stuff.
>
> There's any number of ways one can make a mistake and screw up master.
> That cannot be the reason for forcing a particular workflow on
> everyone, certainly not before any such problems actually happened
> even once.
>
> And I don't understand your fear of unwanted stuff from a divergent
> branch: what exactly is special about this situation?  Surely,
> examining the diffs before committing and pushing would show what is
> about to land on master, so where's the danger that doesn't exist in
> any other commit?

I'm not trying to advocate one or the other, rather just trying to 
understand the reasoning behind the decision.

Personally I always check what I've got locally with gitk or other tool 
which provides an overview of what I'm about to push before I do it. I 
agree that there are more than one way to screw up a master, still, it 
would be prudent to gain from the experience of other similar projects 
even though nothing bad has happened with gdb yet (very likely owing to 
the fact that gdb has only been using git for a couple of months).

> Again, I can understand that some people are accustomed to rebasing,
> and I'm okay with that.  But I don't understand why something that is
> essentially a matter of personal preferences is forced on everyone.
>

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 08:36:25 +0100
> From: Ricard Wanderlof <ricard.wanderlof@axis.com>
> CC: "brobecker@adacore.com" <brobecker@adacore.com>,
> 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> On Thu, 23 Jan 2014, Eli Zaretskii wrote:
> 
> >>
> >> I think it's not the merging per se that is a problem, only if it is done
> >> incorrectly, i.e. merging from a branch that was was broken off from
> >> master a long time ago, which brings in a lot of unwanted stuff.
> >
> > There's any number of ways one can make a mistake and screw up master.
> > That cannot be the reason for forcing a particular workflow on
> > everyone, certainly not before any such problems actually happened
> > even once.
> >
> > And I don't understand your fear of unwanted stuff from a divergent
> > branch: what exactly is special about this situation?  Surely,
> > examining the diffs before committing and pushing would show what is
> > about to land on master, so where's the danger that doesn't exist in
> > any other commit?
> 
> I'm not trying to advocate one or the other, rather just trying to 
> understand the reasoning behind the decision.

So am I.  And I still don't understand that reasoning.

Let me turn the table and ask: are there any objections to removing
this restriction on master, and leaving it only on the branch?  If
there are no objections, can we please remove the restriction?

Re: reject merges on gdb release branches?

[Joel Brobecker]

> > I'm not trying to advocate one or the other, rather just trying to 
> > understand the reasoning behind the decision.
> 
> So am I.  And I still don't understand that reasoning.
> 
> Let me turn the table and ask: are there any objections to removing
> this restriction on master, and leaving it only on the branch?  If
> there are no objections, can we please remove the restriction?

On a personal level, it does not really matter all that much to me,
one way or the other, but from the project's perspective and its
variety of contributors, I would like to object to allowing merge
commits on master. I think we cannot expect all our contributors
to know git well, and for those who don't have a good command of
that tool, branch merges are more difficult to understand than
simple commits.  Rejecting merges makes sure that the history
remains linear.

I still do not understand what the problem is with rebasing though.
You said "loss of information". Can you explain a bit more?

-- 
Joel

Re: reject merges on gdb release branches?

[Doug Evans]

On Thu, Jan 23, 2014 at 11:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 24 Jan 2014 08:36:25 +0100
>> From: Ricard Wanderlof <ricard.wanderlof@axis.com>
>> CC: "brobecker@adacore.com" <brobecker@adacore.com>,
>>       "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> On Thu, 23 Jan 2014, Eli Zaretskii wrote:
>>
>> >>
>> >> I think it's not the merging per se that is a problem, only if it is done
>> >> incorrectly, i.e. merging from a branch that was was broken off from
>> >> master a long time ago, which brings in a lot of unwanted stuff.
>> >
>> > There's any number of ways one can make a mistake and screw up master.
>> > That cannot be the reason for forcing a particular workflow on
>> > everyone, certainly not before any such problems actually happened
>> > even once.
>> >
>> > And I don't understand your fear of unwanted stuff from a divergent
>> > branch: what exactly is special about this situation?  Surely,
>> > examining the diffs before committing and pushing would show what is
>> > about to land on master, so where's the danger that doesn't exist in
>> > any other commit?
>>
>> I'm not trying to advocate one or the other, rather just trying to
>> understand the reasoning behind the decision.
>
> So am I.  And I still don't understand that reasoning.
>
> Let me turn the table and ask: are there any objections to removing
> this restriction on master, and leaving it only on the branch?  If
> there are no objections, can we please remove the restriction?

fwiw, for now at least this git newbie likes the restriction on master
and release branches.

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 00:07:48 -0800
> From: Doug Evans <xdje42@gmail.com>
> Cc: Ricard Wanderlof <ricard.wanderlof@axis.com>, brobecker@adacore.com, 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> fwiw, for now at least this git newbie likes the restriction on master
> and release branches.

Can you explain why?  What possible mistakes do you fear you will make
that this restriction will prevent?

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 12:07:03 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Ricard Wanderlof <ricard.wanderlof@axis.com>,
> 	gdb-patches@sourceware.org
> 
> I think we cannot expect all our contributors to know git well, and
> for those who don't have a good command of that tool, branch merges
> are more difficult to understand than simple commits.

But this sounds backwards.  Merging from a branch is a single git
command, while rebasing requires much more, and requires also
understanding of what rebasing means and does.  We are actually
requiring contributors to know more of git, not less.

Also, isn't git popularity enough for us to not be afraid so much?

In any case, if we fear mistakes by git newbies, why not have a Wiki
page that explains the recommended workflow and commands, and point
contributors to that when they get write access.

> Rejecting merges makes sure that the history remains linear.

This is a strange argument: if we want linear history, why did we
switch to git at all?  dVCS make very little sense, if we want linear
history.  What am I missing?

> I still do not understand what the problem is with rebasing though.
> You said "loss of information". Can you explain a bit more?

The non-linear parts of the development history are deleted.  You can
no longer tell which other branches contributed to a particular
commit.  For example, if a bug happened because you merged from master
half way through feature development, you can no longer see that
merge.  This is an important part of the development history, and is
sometimes invaluable when reflecting on past experience or analyzing
bugs.  I don't see why we should force everyone lose it.

In effect, rebasing is tantamount to preparing diffs, then applying
those diffs on the tip of the master branch: you keep all the textual
changes, but lose the DAG of the flow that led to them.

Again, if we don't care at all about all this, why did we switch to
git?  It sounds like we want a strictly centralized development, which
means about 99% of power of git (or any dVCS, actually) is left off
limits for us.  Is that really the intent?

Re: reject merges on gdb release branches?

[Will Newton]

On 24 January 2014 08:54, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 24 Jan 2014 12:07:03 +0400
>> From: Joel Brobecker <brobecker@adacore.com>
>> Cc: Ricard Wanderlof <ricard.wanderlof@axis.com>,
>>       gdb-patches@sourceware.org
>>
>> I think we cannot expect all our contributors to know git well, and
>> for those who don't have a good command of that tool, branch merges
>> are more difficult to understand than simple commits.
>
> But this sounds backwards.  Merging from a branch is a single git
> command, while rebasing requires much more, and requires also
> understanding of what rebasing means and does.  We are actually
> requiring contributors to know more of git, not less.

From the committers side, yes, disallowing merge commits makes life
slightly harder. You have to rebase your work onto master (or the
branch you wish to commit to) before committing. But from the
perspective of someone browsing the history merge commits are more
complex to understand. Disallowing merge commits is for the benefit of
the future readers of the commit history not for the benefit of the
committer.

The problem with merge commits is they make the history noisy. If I
have a long running development branch I could have lots of:

Merge branch 'master'

Commits that don't serve any function. Yes, they mark that I merged
master at that point, but if the changes do not interact with mine
that is irrelevant and if they do then I no longer have a standalone
commit I can point to as "the feature was added in commit 123abc".

Even worse if people work on master and have a "git commit; git pull;
git push" workflow then you can get almost one merge commit per-commit
which makes browsing the history a real mess.

Merge commits should not be allowed on master or release branches IMO.

-- 
Will Newton
Toolchain Working Group, Linaro

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 10:09:06 +0000
> From: Will Newton <will.newton@linaro.org>
> Cc: Joel Brobecker <brobecker@adacore.com>, ricard.wanderlof@axis.com, 
> 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> The problem with merge commits is they make the history noisy. If I
> have a long running development branch I could have lots of:
> 
> Merge branch 'master'

That's easy enough to skip, if you aren't interested (I am).  I don't
see any real problem here, any development history has some amount of
noise if you are looking for certain things and aren't interested in
others.

> Commits that don't serve any function. Yes, they mark that I merged
> master at that point, but if the changes do not interact with mine
> that is irrelevant

In many, if not most, cases you will not know if they interact or
don't.  Once you've rewritten that part of history, it is lost
forever, even if you later need it.

> and if they do then I no longer have a standalone
> commit I can point to as "the feature was added in commit 123abc".

??? Why not?  When you commit a merge, it doesn't add back the commits
that were on master; you still add only your changes.  The difference
is that, when bisecting later, you will see that a merge introduced a
bug, whereas after a rebase, that merge will no longer be visible, and
it will look as if your changes alone introduced the bug.  Which is a
lie.

> Even worse if people work on master and have a "git commit; git pull;
> git push" workflow then you can get almost one merge commit per-commit
> which makes browsing the history a real mess.

Mess or not, that is really what happened, whereas re-written history
is a lie.

Again, you should be free to rebase if you like, but why can't _I_
merge instead?  Why should your personal preferences constrain my
workflows?

Re: reject merges on gdb release branches?

[Will Newton]

On 24 January 2014 10:28, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 24 Jan 2014 10:09:06 +0000
>> From: Will Newton <will.newton@linaro.org>
>> Cc: Joel Brobecker <brobecker@adacore.com>, ricard.wanderlof@axis.com,
>>       "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> The problem with merge commits is they make the history noisy. If I
>> have a long running development branch I could have lots of:
>>
>> Merge branch 'master'
>
> That's easy enough to skip, if you aren't interested (I am).  I don't
> see any real problem here, any development history has some amount of
> noise if you are looking for certain things and aren't interested in
> others.

That's fine if you have one or two, but in the degenerate case you may
have half your commit history being merges. It's simply not helpful to
anyone.

>> Commits that don't serve any function. Yes, they mark that I merged
>> master at that point, but if the changes do not interact with mine
>> that is irrelevant
>
> In many, if not most, cases you will not know if they interact or
> don't.  Once you've rewritten that part of history, it is lost
> forever, even if you later need it.

The history is not lost, the history is all present. Essentially you
have done the merge yourself (as part of the rebase) and squashed the
merge into the functional commit. Now it is possible you mismerged and
your commit is now bad, but it is still a single atomic change that
can be reverted simply. I would rather deal with that than have to
wade through a number of merge commits to see what cumulative effect
they have. Personal preference perhaps.

>> and if they do then I no longer have a standalone
>> commit I can point to as "the feature was added in commit 123abc".
>
> ??? Why not?  When you commit a merge, it doesn't add back the commits
> that were on master; you still add only your changes.  The difference
> is that, when bisecting later, you will see that a merge introduced a
> bug, whereas after a rebase, that merge will no longer be visible, and
> it will look as if your changes alone introduced the bug.  Which is a
> lie.

Therein lies the issue though, you can only rebase in a single line of
history, so you will only see the merge commit caused the problem even
if it merges many commits.

>> Even worse if people work on master and have a "git commit; git pull;
>> git push" workflow then you can get almost one merge commit per-commit
>> which makes browsing the history a real mess.
>
> Mess or not, that is really what happened, whereas re-written history
> is a lie.

Lie is rather an emotive term don't you think?

> Again, you should be free to rebase if you like, but why can't _I_
> merge instead?  Why should your personal preferences constrain my
> workflows?

As I said, it's not about the committer, it's about the future readers
of the history.

-- 
Will Newton
Toolchain Working Group, Linaro

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 10:35:24 +0000
> From: Will Newton <will.newton@linaro.org>
> Cc: Joel Brobecker <brobecker@adacore.com>, ricard.wanderlof@axis.com, 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> >> The problem with merge commits is they make the history noisy. If I
> >> have a long running development branch I could have lots of:
> >>
> >> Merge branch 'master'
> >
> > That's easy enough to skip, if you aren't interested (I am).  I don't
> > see any real problem here, any development history has some amount of
> > noise if you are looking for certain things and aren't interested in
> > others.
> 
> That's fine if you have one or two, but in the degenerate case you may
> have half your commit history being merges. It's simply not helpful to
> anyone.

It is helpful to anyone who wishes to understand the sequence of
events that led to a certain line being what it is.  Merges are in
important part of that.  E.g., suppose that a merge produced a
conflict whose resolution mistakenly introduced a bug.  If you
eliminate the merge, you will be unable to understand the reasons for
the buggy change, at least not easily.

> >> Commits that don't serve any function. Yes, they mark that I merged
> >> master at that point, but if the changes do not interact with mine
> >> that is irrelevant
> >
> > In many, if not most, cases you will not know if they interact or
> > don't.  Once you've rewritten that part of history, it is lost
> > forever, even if you later need it.
> 
> The history is not lost, the history is all present. Essentially you
> have done the merge yourself (as part of the rebase) and squashed the
> merge into the functional commit.

Yes, and the information in the squashed part is lost.

Anyway, we are going in circles.  I'm not trying to convince you to
change your workflow, I'm asking to allow me to keep mine.

Re: reject merges on gdb release branches?

[Joel Brobecker]

> It is helpful to anyone who wishes to understand the sequence of
> events that led to a certain line being what it is.  Merges are in
> important part of that.  E.g., suppose that a merge produced a
> conflict whose resolution mistakenly introduced a bug.  If you
> eliminate the merge, you will be unable to understand the reasons for
> the buggy change, at least not easily.

If there are conflicts between your branch and the master branch,
and those conflicts are not trivial to resolve, the commits needs
to be reviewed again. Otherwise, you would essentially be pushing
an unreviewed commits (the merge commit).

> Anyway, we are going in circles.  I'm not trying to convince you to
> change your workflow, I'm asking to allow me to keep mine.

But this is at the cost of everyone else finding it more difficult
afterwards each time they consult the history.

-- 
Joel

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 14:58:07 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Will Newton <will.newton@linaro.org>, ricard.wanderlof@axis.com,
> 	gdb-patches@sourceware.org
> 
> > It is helpful to anyone who wishes to understand the sequence of
> > events that led to a certain line being what it is.  Merges are in
> > important part of that.  E.g., suppose that a merge produced a
> > conflict whose resolution mistakenly introduced a bug.  If you
> > eliminate the merge, you will be unable to understand the reasons for
> > the buggy change, at least not easily.
> 
> If there are conflicts between your branch and the master branch,
> and those conflicts are not trivial to resolve, the commits needs
> to be reviewed again.

Of course.  I'm talking about the situation after they are resolved
and the result is committed.

> > Anyway, we are going in circles.  I'm not trying to convince you to
> > change your workflow, I'm asking to allow me to keep mine.
> 
> But this is at the cost of everyone else finding it more difficult
> afterwards each time they consult the history.

What difficulty are you talking about?  Can you demonstrate on a real
history log that difficulty?

Re: reject merges on gdb release branches?

[Joel Brobecker]

[resending without the png attachement - the list rejects png]

On Fri, Jan 24, 2014 at 03:30:14PM +0400, Joel Brobecker wrote:
> > > If there are conflicts between your branch and the master branch,
> > > and those conflicts are not trivial to resolve, the commits needs
> > > to be reviewed again.
> > 
> > Of course.  I'm talking about the situation after they are resolved
> > and the result is committed.
> 
> So, concretely, you would also send the merge commit as an extra commit
> for review?
> 
> > > > Anyway, we are going in circles.  I'm not trying to convince you to
> > > > change your workflow, I'm asking to allow me to keep mine.
> > > 
> > > But this is at the cost of everyone else finding it more difficult
> > > afterwards each time they consult the history.
> > 
> > What difficulty are you talking about?  Can you demonstrate on a real
> > history log that difficulty?
> 
> Sure. Attached is a gittk screenshot.
> 
> This discussion is taking more time than I have, unfortunately.
> I'll probably let you guys discuss it out, and I will live with
> the outcome. I'll have to say that this discussion did reinforce
> my feeling that the current rule has more benefits than drawbacks.

-- 
Joel

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 15:30:14 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: will.newton@linaro.org, ricard.wanderlof@axis.com,
> 	gdb-patches@sourceware.org
> 
> > > If there are conflicts between your branch and the master branch,
> > > and those conflicts are not trivial to resolve, the commits needs
> > > to be reviewed again.
> > 
> > Of course.  I'm talking about the situation after they are resolved
> > and the result is committed.
> 
> So, concretely, you would also send the merge commit as an extra commit
> for review?

I'm not talking about review: for review we send and receive diffs,
not commits with their metadata.  I'm talking about the history DAG
after the commit and the push.  And, as you well know, a merge that
causes conflicts requires a commit after resolving those conflicts.

> > > > Anyway, we are going in circles.  I'm not trying to convince you to
> > > > change your workflow, I'm asking to allow me to keep mine.
> > > 
> > > But this is at the cost of everyone else finding it more difficult
> > > afterwards each time they consult the history.
> > 
> > What difficulty are you talking about?  Can you demonstrate on a real
> > history log that difficulty?
> 
> Sure. Attached is a gittk screenshot.

And what exactly are the difficulties with that?

> I'll have to say that this discussion did reinforce my feeling that
> the current rule has more benefits than drawbacks.

Sure, since benefits are yours, while drawbacks are mine ;-)

I'm asking to free me from the tyranny of this rule.  You are free to
apply it in your work, but I still see no reasons to force me.  You
are used to rebase, so you think a DAG with merges is somehow more
complicated; it isn't.

Re: reject merges on gdb release branches?

[Joel Brobecker]

> I'm not talking about review: for review we send and receive diffs,
> not commits with their metadata.  I'm talking about the history DAG
> after the commit and the push.  And, as you well know, a merge that
> causes conflicts requires a commit after resolving those conflicts.

I don't understand what you mean, anymore.

> > Sure. Attached is a gittk screenshot.
> 
> And what exactly are the difficulties with that?

I can guaranty you that most people will find this non-linear history
at best hard to follow, at worst plain confusing. I consider myself
relatively well versed in git, and yet I consider this type of history
to be fairly hard to follow. While you do not seem to have trouble
with it, you have to think about the others.

> > I'll have to say that this discussion did reinforce my feeling that
> > the current rule has more benefits than drawbacks.
> 
> Sure, since benefits are yours, while drawbacks are mine ;-)
> 
> I'm asking to free me from the tyranny of this rule.  You are free to
> apply it in your work, but I still see no reasons to force me.  You
> are used to rebase, so you think a DAG with merges is somehow more
> complicated; it isn't.

We'll have to agree to disagree, then (and I use merges routinely,
so I think I also have a good handle on them). The problem I have
with your request is that we're trading a one-off operation (merge
vs rebase) against a history that is necessarily more complicated.
And most, if not all people who expressed an opinion, confirmed that.

I apologize in advance, but I have to disengage from this discussion.
I think I've exposed my arguments, and have nothing else to add.
As I said, I will live with the outcome, whatever it is.

-- 
Joel

Re: reject merges on gdb release branches?

[Eli Zaretskii]

[Resending because the list rejected the attachment.]

> Date: Fri, 24 Jan 2014 15:55:48 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: will.newton@linaro.org, ricard.wanderlof@axis.com,	gdb-patches@sourceware.org
> 
> > I'm not talking about review: for review we send and receive diffs,
> > not commits with their metadata.  I'm talking about the history DAG
> > after the commit and the push.  And, as you well know, a merge that
> > causes conflicts requires a commit after resolving those conflicts.
> 
> I don't understand what you mean, anymore.

Sorry about that.  What I meant to say was that the merge vs rebase
issue is not relevant to patch review.

> > > Sure. Attached is a gittk screenshot.
> > 
> > And what exactly are the difficulties with that?
> 
> I can guaranty you that most people will find this non-linear history
> at best hard to follow, at worst plain confusing. I consider myself
> relatively well versed in git, and yet I consider this type of history
> to be fairly hard to follow. While you do not seem to have trouble
> with it, you have to think about the others.

In Emacs development, we don't have any trouble with even more
complicated DAG structures.  See the attached for a (relatively
simple) example.

> We'll have to agree to disagree, then (and I use merges routinely,
> so I think I also have a good handle on them). The problem I have
> with your request is that we're trading a one-off operation (merge
> vs rebase) against a history that is necessarily more complicated.
> And most, if not all people who expressed an opinion, confirmed that.

Why does this issue have to be decided by a majority?

Re: reject merges on gdb release branches?

[H.J. Lu]

On Fri, Jan 24, 2014 at 6:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> [Resending because the list rejected the attachment.]
>
>> Date: Fri, 24 Jan 2014 15:55:48 +0400
>> From: Joel Brobecker <brobecker@adacore.com>
>> Cc: will.newton@linaro.org, ricard.wanderlof@axis.com,        gdb-patches@sourceware.org
>>
>> > I'm not talking about review: for review we send and receive diffs,
>> > not commits with their metadata.  I'm talking about the history DAG
>> > after the commit and the push.  And, as you well know, a merge that
>> > causes conflicts requires a commit after resolving those conflicts.
>>
>> I don't understand what you mean, anymore.
>
> Sorry about that.  What I meant to say was that the merge vs rebase
> issue is not relevant to patch review.
>
>> > > Sure. Attached is a gittk screenshot.
>> >
>> > And what exactly are the difficulties with that?
>>
>> I can guaranty you that most people will find this non-linear history
>> at best hard to follow, at worst plain confusing. I consider myself
>> relatively well versed in git, and yet I consider this type of history
>> to be fairly hard to follow. While you do not seem to have trouble
>> with it, you have to think about the others.
>
> In Emacs development, we don't have any trouble with even more
> complicated DAG structures.  See the attached for a (relatively
> simple) example.
>
>> We'll have to agree to disagree, then (and I use merges routinely,
>> so I think I also have a good handle on them). The problem I have
>> with your request is that we're trading a one-off operation (merge
>> vs rebase) against a history that is necessarily more complicated.
>> And most, if not all people who expressed an opinion, confirmed that.
>
> Why does this issue have to be decided by a majority?

I use both rebase and merge. I use merge on hjl/linux/master
branch since I need to go back to checkout previous trees on
my branch. Rebase won't work for me here.

But for hjl/mpx/pltext8 branch, I use rebase since I
plan to commit it to master when the work is complete
and I don't need to go back in history.

I don't care about the history of each commit on master
and release branches.  Merge will only confuse me.
But you can tag your merged commit before rebase or
create a branch for it.  All history will be there for you
and it won't confuse other people.


-- 
H.J.

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 06:45:11 -0800
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, Will Newton <will.newton@linaro.org>, 
> 	ricard.wanderlof@axis.com, GDB <gdb-patches@sourceware.org>
> 
> I use both rebase and merge. I use merge on hjl/linux/master
> branch since I need to go back to checkout previous trees on
> my branch. Rebase won't work for me here.
> 
> But for hjl/mpx/pltext8 branch, I use rebase since I
> plan to commit it to master when the work is complete
> and I don't need to go back in history.
> 
> I don't care about the history of each commit on master
> and release branches.  Merge will only confuse me.
> But you can tag your merged commit before rebase or
> create a branch for it.  All history will be there for you
> and it won't confuse other people.

There's any number of workflows that git allows.  As long as master
only gets pushes that add commits, I don't see why we should force a
particular workflow and disallow all others.  You should be able to
use yours, and I should be able to use mine.  Sorry, but I refuse to
believe that people who develop and maintain GDB and Binutils are
confused by a DAG that has a few merges.

Re: reject merges on gdb release branches?

[H.J. Lu]

On Fri, Jan 24, 2014 at 7:44 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 24 Jan 2014 06:45:11 -0800
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>> Cc: Joel Brobecker <brobecker@adacore.com>, Will Newton <will.newton@linaro.org>,
>>       ricard.wanderlof@axis.com, GDB <gdb-patches@sourceware.org>
>>
>> I use both rebase and merge. I use merge on hjl/linux/master
>> branch since I need to go back to checkout previous trees on
>> my branch. Rebase won't work for me here.
>>
>> But for hjl/mpx/pltext8 branch, I use rebase since I
>> plan to commit it to master when the work is complete
>> and I don't need to go back in history.
>>
>> I don't care about the history of each commit on master
>> and release branches.  Merge will only confuse me.
>> But you can tag your merged commit before rebase or
>> create a branch for it.  All history will be there for you
>> and it won't confuse other people.
>
> There's any number of workflows that git allows.  As long as master
> only gets pushes that add commits, I don't see why we should force a
> particular workflow and disallow all others.  You should be able to
> use yours, and I should be able to use mine.  Sorry, but I refuse to
> believe that people who develop and maintain GDB and Binutils are
> confused by a DAG that has a few merges.

How can you do "git bisect" with merged commits?  I
know I can't do git bisect" on hjl/linux/applied branch
since I use merge on it.

-- 
H.J.

Re: reject merges on gdb release branches?

[Eli Zaretskii]

> Date: Fri, 24 Jan 2014 07:49:08 -0800
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, Will Newton <will.newton@linaro.org>, 
> 	ricard.wanderlof@axis.com, GDB <gdb-patches@sourceware.org>
> 
> How can you do "git bisect" with merged commits?  I

Like this:

  https://gist.github.com/canton7/3737126

And in any case, if somehow this is not your case, you can always
start a new bisect with the commits on the branch as start and end
points.

Re: reject merges on gdb release branches?

[H.J. Lu]

On Fri, Jan 24, 2014 at 8:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 24 Jan 2014 07:49:08 -0800
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>> Cc: Joel Brobecker <brobecker@adacore.com>, Will Newton <will.newton@linaro.org>,
>>       ricard.wanderlof@axis.com, GDB <gdb-patches@sourceware.org>
>>
>> How can you do "git bisect" with merged commits?  I
>
> Like this:
>
>   https://gist.github.com/canton7/3737126
>
> And in any case, if somehow this is not your case, you can always
> start a new bisect with the commits on the branch as start and end
> points.

I may live with this complicated workaround on my personal branches.
But I won't force it upon other developers.

-- 
H.J.

Re: reject merges on gdb release branches?

[Andreas Schwab]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> How can you do "git bisect" with merged commits?

It works perfectly well with merges.  How would you think the kernel
people can get away with it?

> I know I can't do git bisect" on hjl/linux/applied branch since I use
> merge on it.

How do you "know"?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."