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: gdb-patches at sourceware dot org
- Date: Wed, 22 Jan 2014 20:15:20 +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>
> Doesn't that mean you are forcing everybody to rebase before
> committing from feature branches? If so, that sounds drastic, and
> should have very good reasons. (Apologies if this was already
> discussed and decided, but in that case I'd appreciate a pointer.)
IIUC, you're asking a general question: Is it OK to do a merge of
a feature branch onto another, and then push that branch?
The currently situation, as discussed during the transition to git,
was that this is not allowed for the "master" branch. Note that
a rebase, compared to a merge, is not that much more work, and has
the nice property of keeping the history linear. I've been managing
patch series of 20+ patches, with regular rebases, without problems.
It's something you do anyway in order to submit the patches, so
I don't think this is an issue in practice.
This proposal is to extend this restriction to all GDB release branches,
for the reasons detailed in my reply to Yao. Basically, this is to
avoid mistakes resulting us in merging more than what you intended.
--
Joel