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