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

Ramkumar Ramachandra [off-list ref] writes:

Okay, just to make sure I understand this correctly: if more than one
argument is literally specified, I should not set up the revision
walker and pick the commits listed in revs->pending, correct?

Not really.

A rough approximation would be that if you see any negative ones (either
coming from A..B or ^A), you would always want to walk, giving everything
to prepare_revision_walk()-and-then-get_revision() machiery.

Otherwise you have only zero [*1*] or more positive ones, and you pick
them in the order you find in the pending list, without bothering the
revision traversal machinery at all [*2*].

when I encounter the following command,

  $ git cherry-pick maint ^master

I should just pick two commits: maint, and ^master.

So the answer is aboslutely no. "maint ^master" is the same as saying
"master..maint".

[Footnote]

*1* You would probably want to error out if you got zero positive ones in
this case (i.e. absolutely nothing was given, neither positive nor
negative).

*2* The reason this is "rough" approximation is because we would probably
want to do Jonathan's "maint..master master..next" someday, and when that
happens, we would need to do much more than "do we have any negative? then
send it through to prepare_revision_walk()". But we are not there yet, so
I think the above is actually more or less the complete implementation.