Hi, On Thu, Jan 12, 2012 at 02:31:30PM +0100, Christian Couder wrote: > Hi all, > > 2012/1/11 SZEDER Gábor <szeder@xxxxxxxxxx>: > > > > As far as I can tell, this buggy behavior is as old as multi-commit > > cherry-pick itself, i.e. 7e2bfd3f (revert: allow cherry-picking more > > than one commit, 2010-06-02). > > 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. Besides, AFAICT, parse_args() sets opts->revs->no_walk = 1, which will cause prepare_revision_walk() to return before it would reach the topo_order condition, so opts->revs->topo_order = 1 wouldn't have any effect. Best, Gábor -- 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