This is the mail archive of the
mailing list for the binutils project.
Re: reject merges on gdb release branches?
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, Binutils <binutils at sourceware dot org>
- Cc: Eli Zaretskii <eliz at gnu dot org>, GDB <gdb-patches at sourceware dot org>
- Date: Wed, 22 Jan 2014 08:23:43 -0800
- 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>
On Wed, Jan 22, 2014 at 8:15 AM, Joel Brobecker <email@example.com> wrote:
>> 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.
Add binutils mailing list.
I think it is a good idea and it should be extended to all binutils
Thanks for doing this.