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:48:53 +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> <83a9eleksf dot fsf at gnu dot org> <CANu=Dmh39cA462XRa=+254n3CwZ5M3peAQBhN-bhV6A6OuXuzQ at mail dot gmail dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 24 Jan 2014 10:35:24 +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.
It is helpful to anyone who wishes to understand the sequence of
events that led to a certain line being what it is. Merges are in
important part of that. E.g., suppose that a merge produced a
conflict whose resolution mistakenly introduced a bug. If you
eliminate the merge, you will be unable to understand the reasons for
the buggy change, at least not easily.
> >> 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.
Yes, and the information in the squashed part is lost.
Anyway, we are going in circles. I'm not trying to convince you to
change your workflow, I'm asking to allow me to keep mine.