Re: reject merges on gdb release branches?

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, Jan 22, 2014 at 8:15 AM, Joel Brobecker <brobecker@adacore.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
release branches.

Thanks for doing this.

-- 
H.J.