Re: reject merges on gdb release branches?

[Eli Zaretskii <eliz@gnu.org>]

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