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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Will Newton <will dot newton at linaro dot org>, ricard dot wanderlof at axis dot com, GDB <gdb-patches at sourceware dot org>
- Date: Fri, 24 Jan 2014 06:45:11 -0800
- Subject: Re: reject merges on gdb release branches?
- Authentication-results: sourceware.org; auth=none
- References: <20140124080703 dot GL4762 at adacore dot com> <83eh3xep43 dot fsf at gnu dot org> <CANu=DmhEyNvF3au1r+zyrZ2B368iA8PF3hh3cWMM2Hhwa1mpYw at mail dot gmail dot com> <83a9eleksf dot fsf at gnu dot org> <CANu=Dmh39cA462XRa=+254n3CwZ5M3peAQBhN-bhV6A6OuXuzQ at mail dot gmail dot com> <838uu5eju2 dot fsf at gnu dot org> <20140124105807 dot GM4762 at adacore dot com> <837g9peirg dot fsf at gnu dot org> <20140124113014 dot GN4762 at adacore dot com> <8361p9ehht dot fsf at gnu dot org> <20140124115548 dot GO4762 at adacore dot com> <83wqhpcv4z dot fsf at gnu dot org>
On Fri, Jan 24, 2014 at 6:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> [Resending because the list rejected the attachment.]
>
>> Date: Fri, 24 Jan 2014 15:55:48 +0400
>> From: Joel Brobecker <brobecker@adacore.com>
>> Cc: will.newton@linaro.org, ricard.wanderlof@axis.com, gdb-patches@sourceware.org
>>
>> > I'm not talking about review: for review we send and receive diffs,
>> > not commits with their metadata. I'm talking about the history DAG
>> > after the commit and the push. And, as you well know, a merge that
>> > causes conflicts requires a commit after resolving those conflicts.
>>
>> I don't understand what you mean, anymore.
>
> Sorry about that. What I meant to say was that the merge vs rebase
> issue is not relevant to patch review.
>
>> > > Sure. Attached is a gittk screenshot.
>> >
>> > And what exactly are the difficulties with that?
>>
>> I can guaranty you that most people will find this non-linear history
>> at best hard to follow, at worst plain confusing. I consider myself
>> relatively well versed in git, and yet I consider this type of history
>> to be fairly hard to follow. While you do not seem to have trouble
>> with it, you have to think about the others.
>
> In Emacs development, we don't have any trouble with even more
> complicated DAG structures. See the attached for a (relatively
> simple) example.
>
>> We'll have to agree to disagree, then (and I use merges routinely,
>> so I think I also have a good handle on them). The problem I have
>> with your request is that we're trading a one-off operation (merge
>> vs rebase) against a history that is necessarily more complicated.
>> And most, if not all people who expressed an opinion, confirmed that.
>
> Why does this issue have to be decided by a majority?
I use both rebase and merge. I use merge on hjl/linux/master
branch since I need to go back to checkout previous trees on
my branch. Rebase won't work for me here.
But for hjl/mpx/pltext8 branch, I use rebase since I
plan to commit it to master when the work is complete
and I don't need to go back in history.
I don't care about the history of each commit on master
and release branches. Merge will only confuse me.
But you can tag your merged commit before rebase or
create a branch for it. All history will be there for you
and it won't confuse other people.
--
H.J.