From: Jonathan Nieder <jrnieder@gmail.com>
Date: Thu, 12 Jan 2012 20:11:22 GMT
Subject: Re: [BUG] multi-commit cherry-pick messes up the order of commits
Message-ID: <20120112201122.GE6038@burratino>
In-Reply-To: <20120112194710.GA28148@sigill.intra.peff.net>

Jeff King wrote:

> I am tempted to suggest
[...]
>              That would make all of these work as most people would
> expect:
>
>   git cherry-pick A B C
>   git cherry-pick A..B
>   git cherry-pick A..B B..C
>
> but would be a regression for:
>
>   git cherry-pick B ^A
>
> versus the current code. I suspect that the latter form is not all that
> commonly used, though, and certainly I would accept it as a casualty of
> making the "A B C" form work. My only hesitation is that it is in fact a
> regression.

I find myself using such complicated expressions as

	list-revs-to-skip |
	xargs git cherry-pick --cherry-pick --right-only HEAD...topic --not

so yeah, that would be a pretty serious loss in functionality.

However, moving to something like the far future semantics that Junio
hinted at, for cherry-pick/revert and other --no-walk style commands
only, would not be a regression for me.  The multi-pick feature is
still young, and I _suspect_ changing the meaning of A..B B..C for it
would not inconvenience anybody.

I would even welcome a change in the meaning of B ^A: the most
intuitive thing for it to do would be to cherry-pick the single commit B
when and only when it is not an ancestor of A.

Jonathan