This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reject merges on gdb release branches?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]