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: Joel Brobecker <brobecker at adacore dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Will Newton <will dot newton at linaro dot org>, ricard dot wanderlof at axis dot com, gdb-patches at sourceware dot org
- Date: Fri, 24 Jan 2014 14:58:07 +0400
- Subject: Re: reject merges on gdb release branches?
- Authentication-results: sourceware.org; auth=none
- References: <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> <838uu5eju2 dot fsf at gnu dot org>
> 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.
If there are conflicts between your branch and the master branch,
and those conflicts are not trivial to resolve, the commits needs
to be reviewed again. Otherwise, you would essentially be pushing
an unreviewed commits (the merge commit).
> 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.
But this is at the cost of everyone else finding it more difficult
afterwards each time they consult the history.
--
Joel