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: Ricard Wanderlof <ricard dot wanderlof at axis dot com>, gdb-patches at sourceware dot org
- Date: Fri, 24 Jan 2014 12:07:03 +0400
- 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>
> > I'm not trying to advocate one or the other, rather just trying to
> > understand the reasoning behind the decision.
>
> So am I. And I still don't understand that reasoning.
>
> Let me turn the table and ask: are there any objections to removing
> this restriction on master, and leaving it only on the branch? If
> there are no objections, can we please remove the restriction?
On a personal level, it does not really matter all that much to me,
one way or the other, but from the project's perspective and its
variety of contributors, I would like to object to allowing merge
commits on master. 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. Rejecting merges makes sure that the history
remains linear.
I still do not understand what the problem is with rebasing though.
You said "loss of information". Can you explain a bit more?
--
Joel