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

From: SZEDER Gábor <szeder@ira.uka.de>
Date: Jan 12, 2012, 14:44 UTC
Message-ID: <20120112144409.GV30469@goldbirke>
In-Reply-To: <CAP8UFD2uLoqzXRxssjwwW1Vk8RuNF_5OT1d7Z7hiRQ+Rq=UM1A@mail.gmail.com>

Hi,

On Thu, Jan 12, 2012 at 02:31:30PM +0100, Christian Couder wrote:

Show 18 quoted lines

> Hi all,
> 
> 2012/1/11 SZEDER Gábor <szeder@ira.uka.de>:
> >
> > 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