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

From: Jeff King <peff@peff.net>
Date: Jan 12, 2012, 20:17 UTC
Message-ID: <20120112201710.GA31427@sigill.intra.peff.net>
In-Reply-To: <20120112201122.GE6038@burratino>

On Thu, Jan 12, 2012 at 02:11:22PM -0600, Jonathan Nieder wrote:

Show 24 quoted lines

> > 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.

That's gross. :)

But thank you for providing a real-world example. I had a vague notion that the full power of the revision parser was not actually useful to people, but clearly not.

OTOH, if cherry-pick were more simplistic, you could perhaps get by with:

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

-Peff