Re: reject merges on gdb release branches?

[Will Newton <will.newton@linaro.org>]

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