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

From: Jeff King <peff@peff.net>
Date: Jan 12, 2012, 16:53 UTC
Message-ID: <20120112165329.GA17173@sigill.intra.peff.net>
In-Reply-To: <20120112144409.GV30469@goldbirke>

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

Show 16 quoted lines

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