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

From: Johannes Sixt <j6t@kdbg.org>
Date: May 23, 2012, 18:59 UTC
Message-ID: <4FBD3391.7010905@kdbg.org>
In-Reply-To: <CAOeW2eE9EW3gER7ZDThGABtZ0doNuUb70DnKrnzD+OeWYLO7cQ@mail.gmail.com>

Am 23.05.2012 17:37, schrieb Martin von Zweigbergk:

Show 13 quoted lines

> On Mon, May 21, 2012 at 1:19 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> Replace the 'git merge' by a cherry-pick that picks the changes that the
>> merge introduces with respect to the first parent.
> 
> Just a reminder of what I said in [1] (the same thread that you referenced):
> 
> I think this will break "git rebase -p --onto g b f" on  the below history.
> 
>           .-e-.
>          /     \
>       .-c---d---f
>      /
> a---b---g

This still works. It is tested by t3411.3.

Show 5 quoted lines

> Even if this wasn't the intended use case, git currently supports it
> and I would personally be a little surprised if no one has gotten used
> to it working. So should we at least check for this case and handle it
> with "git merge" as usual? Or stop supporting it and error out instead
> (and mention in release notes?)?

YESSS, drop it. It would allow us to remove all sorts of crufty work-arounds for work-arounds. THIS IS NOT 'git sequencer'!

Show 5 quoted lines

> Btw, with a history without "internal" merges, but where the merge
> commit was generated "backwards" so the first parent is not in the
> to-be-rebased history, am I correct in thinking that the "git
> cherry-pick -m 1" will fail? Do you think we should consider this case
> or do we consider that too broken to care about?

I think something odd will happen. If in doubt, I would suggest to consider this such an odd case which rebase is not intended for ;-) (garbage in - garbage out).

-- Hannes