Re: [BUG] multi-commit cherry-pick messes up the order of commits

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 12, 2012, 20:11 UTC
Message-ID: <20120112201122.GE6038@burratino>
In-Reply-To: <20120112194710.GA28148@sigill.intra.peff.net>

Jeff King wrote:

> I am tempted to suggest

[...]

Show 15 quoted lines

>              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