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

Hi Peff,

Jeff King wrote:

It may even be possible to use
heuristics to identify when --literal-order is needed, and eventually it
could go away.

Yeah, that would be really nice.

My only concern is that there are other parts of the revision machinery
that depend on the date-ordering of the commit list.

Agreed.  Looking at it another way, it's an opportunity to read
revision.c, learn, and modernize some older parts :)

What would happen,
for example, with:

 git rev-list --literal-order --do-walk foo

It probably doesn't make sense to allow literal-order without no-walk,
anyway (which of course is the default in cherry-pick anyway, so it's
not a big deal here).

I don't know if that particular case is a problem: there are some
mutually exclusive options in revision.c already like:

  cannot combine --reverse with --graph

This'll just be another one of them.

I'm also not sure what:

 git rev-list --literal-order foo..bar

would or should do.

Instead of classifying it as an "ordering" option (as defined in
Documentation/rev-list-options.txt), I think we should give it some
sort of special status for now -- it can be combined with ordering
options (of which date ordering is default anyway).  For this specific
question, I suspect that revision.c does a topo-ordering for commit
ranges (I haven't read the code), so we have to make sure that
whatever extra logic we add doesn't disrupt the existing logic in
revision.c.

-- Ram