Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 24, 2012 at 10:31 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]