This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: reject merges on gdb release branches?
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: brobecker at adacore dot com, ricard dot wanderlof at axis dot com, gdb-patches at sourceware dot org
- Date: Fri, 24 Jan 2014 12:28:16 +0200
- Subject: Re: reject merges on gdb release branches?
- Authentication-results: sourceware.org; auth=none
- References: <20140122051133 dot GB4762 at adacore dot com> <83r480f2r2 dot fsf at gnu dot org> <20140122161520 dot GF4762 at adacore dot com> <83bnz4ezst dot fsf at gnu dot org> <alpine dot DEB dot 2 dot 00 dot 1401230838060 dot 24884 at lnxricardw dot se dot axis dot com> <83wqhqekpp dot fsf at gnu dot org> <alpine dot DEB dot 2 dot 00 dot 1401240833360 dot 24884 at lnxricardw dot se dot axis dot com> <83ha8tersb dot fsf at gnu dot org> <20140124080703 dot GL4762 at adacore dot com> <83eh3xep43 dot fsf at gnu dot org> <CANu=DmhEyNvF3au1r+zyrZ2B368iA8PF3hh3cWMM2Hhwa1mpYw at mail dot gmail dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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?