Re: reject merges on gdb release branches?

[Eli Zaretskii <eliz@gnu.org>]

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