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

Hi,

I did some multi-commit cherry-picks lately, and noticed that sometimes cherry-pick applied the commits in different order than I specified on the command line. After some debugging, today I could finally come up with a receipe to reproduce:

  git init
  echo 1 >a && git add a
  git commit -m a
  echo 2 >b && git add b
  git commit -m b
  sleep 2 && echo 3 >c && git add c
  git commit -m c
  git checkout -b branch HEAD^^
  git cherry-pick master master^    # the later commit first

where the 'git cherry-pick' command produces the following output:

[branch ef5b86e0] b
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 b
[branch 6a74f934] c
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 c

Notice that master^, i.e. the commit adding the file 'b', is picked before master, i.e. the commit adding 'c', although the order on the command line was the reverse.

This is because

  cmd_cherry_pick()
    pick_revisions()
      walk_revs_populate_todo()
        prepare_revs()

calls prepare_revision_walk(), which parses the commits from the command line in the order they were specified, but inserts them into a list ordered by date, and commits will be picked in the order they appear in this list. So if you specify commits in a different order than their committer date or commits with the same commiter date (which are often produced by am, rebase, and multi-commit cherry-pick), then they will be picked in wrong order.

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).

Best, Gábor