Re: reject merges on gdb release branches?

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

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