Re: reject merges on gdb release branches?

[Eli Zaretskii <eliz@gnu.org>]

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