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

[Jeff King <peff@peff.net>]

On Thu, Jan 12, 2012 at 03:44:09PM +0100, SZEDER Gábor wrote:

> > Thanks for the very detailed report!
> > 
> > I didn't test nor even compiled anything but maybe this can be fixed
> > by adding something like:
> > 
> > opts->revs->topo_order = 1;
> > 
> > in parse_args() or in prepare_revs()
> > 
> > I will try to have a look tonight.
> 
> [Beware, I'm mostly clueless about git internals.]
> 
> I don't think that any commit reordering, whether it's based on
> committer date, topology, or whatever, is acceptable.  Commits must be
> picked in the exact order they are specified on the command line.

I thought the multi-commit cherry-pick was supposed to take arbitrary
revision arguments, so you can do:

  git cherry-pick master..topic

and likewise you can spell it:

  git cherry-pick topic ^master

or:

  git cherry-pick ^master topic

So the order of arguments isn't relevant in those cases; the graph
ordering is. I agree it would be nice to make:

  git cherry-pick commit1 commit3 commit2

work in the order specified, but how does that interact with existing
cases that provide more traditional revision arguments?

-Peff