Am 23.05.2012 17:37, schrieb Martin von Zweigbergk: > 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 This still works. It is tested by t3411.3. > 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'! > 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 -- 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