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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html