The invocation
$ git cherry-pick commit3 commit1 commit2
picks commits after sorting by date order, which is counter-intuitive.
Add a failing test to t3508 (cherry-pick-many-commits) documenting
this behavior.
Signed-off-by: Ramkumar Ramachandra <redacted>
---
Had some weird compulsion to conform to the style of the other tests
in the previous iteration.
t/t3508-cherry-pick-many-commits.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/t/t3508-cherry-pick-many-commits.sh b/t/t3508-cherry-pick-many-commits.sh
index 8e09fd0..d9d632d 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -59,6 +59,23 @@ test_expect_success 'cherry-pick first..fourth works' '
check_head_differs_from fourth
'
+test_expect_failure 'cherry-pick picks commits in the order requested' '
+ git checkout -f master &&
+ git reset --hard first &&
+ test_tick &&
+ git cherry-pick fourth second third &&
+ {
+ git rev-list --reverse HEAD |
+ git diff-tree --stdin -s --format=%s
+ } >actual &&
+ cat >expect <<-\EOF &&
+ fourth
+ second
+ third
+ EOF
+ test_cmp expect actual
+'
+
test_expect_success 'cherry-pick --strategy resolve first..fourth works' '
cat <<-\EOF >expected &&
Trying simple merge.--
1.7.8.2