On Mon, May 21, 2012 at 1:19 PM, Johannes Sixt <j6t@xxxxxxxx> 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
--
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