The culprit is actually not cherry-pick, but a special code path that expects refresh_cache_entry() not to return NULL. And the fix is to teach it to handle NULL there. This bug was brought to my attention by Markus Klein via https://github.com/git-for-windows/git/issues/952. Changes since v1: - changed test title - avoided ambiguous refname in test Johannes Schindelin (2): cherry-pick: demonstrate a segmentation fault Avoid a segmentation fault with renaming merges merge-recursive.c | 2 ++ t/t3501-revert-cherry-pick.sh | 12 ++++++++++++ 2 files changed, 14 insertions(+) base-commit: e2b2d6a172b76d44cb7b1ddb12ea5bfac9613a44 Published-As: https://github.com/dscho/git/releases/tag/cherry-pick-segfault-v2 Fetch-It-Via: git fetch https://github.com/dscho/git cherry-pick-segfault-v2 Interdiff vs v1: diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh index 8e21840f11..4f2a263b63 100755 --- a/t/t3501-revert-cherry-pick.sh +++ b/t/t3501-revert-cherry-pick.sh @@ -141,7 +141,7 @@ test_expect_success 'cherry-pick "-" works with arguments' ' test_cmp expect actual ' -test_expect_success 'cherry-pick fails gracefully with dirty renamed file' ' +test_expect_success 'cherry-pick works with dirty renamed file' ' test_commit to-rename && git checkout -b unrelated && test_commit unrelated && @@ -150,7 +150,7 @@ test_expect_success 'cherry-pick fails gracefully with dirty renamed file' ' test_tick && git commit -m renamed && echo modified >renamed && - git cherry-pick unrelated + git cherry-pick refs/heads/unrelated ' test_done -- 2.11.0.rc3.windows.1