Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes
- From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
- Date
- May 24, 2012, 17:47 UTC
- Message-ID
- <CAOeW2eH85+qa2PXS55_xGwH+tpMDMEK76HywfpLTYrv_Dtg49Q@mail.gmail.com>
- In-Reply-To
- <7vehq9xz7a.fsf@alter.siamese.dyndns.org>
On Thu, May 24, 2012 at 10:31 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes: > >> Yes, I've had the same idea myself. Anyway, as Johannes said, that's >> probably something to consider for the sequencer. > > Are you saying that "rebase -any-variant" and the sequencer should behave > differently? It is not immediately obvious to me why it is a good idea.
That's not what I meant to say. I thought the sequencer is supposed to replace much of git-rebase and I thought that's what Johannes was referring to as well when he said not to make git-rebase too intelligent. I assumed the reasoning was that any work spent on git-rebase at this point will be thrown away once git-rebase instead calls into the sequencer. But I have not been very involved in the discussions about the sequencer, so I may very well have misunderstood things. Or are you saying that even if it's true that git-rebase will eventually call into the sequencer for much of its operation, this specific part (if at all implemented) does not belong in the sequencer?
Martin