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 23, 2012, 15:37 UTC
Message-ID: <CAOeW2eE9EW3gER7ZDThGABtZ0doNuUb70DnKrnzD+OeWYLO7cQ@mail.gmail.com>
In-Reply-To: <4FBAA33D.1080703@kdbg.org>

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

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?)?

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?

Martin

 [1] http://thread.gmane.org/gmane.comp.version-control.git/194434/focus=194786