'stash apply' directly calls a backend merge function
which does not automatically invoke rerere. This
confuses mergetool when leftover rerere state is left
behind from previous merges.
Invoke rerere explicitly when we encounter a conflict
during stash apply
Change the test for this flaw to expect success.
Signed-off-by: Phil Hord <ho...@cisco.com>
Mentored-by: Junio C Hamano <gits...@pobox.com>
---
git-stash.sh | 1 +
t/t7610-mergetool.sh | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-stash.sh b/git-stash.sh
index 4e2c7f8..bbefdf6 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -469,6 +469,7 @@ apply_stash () {
else
# Merge conflict; keep the exit status from merge-recursive
status=$?
+ git rerere
if test -n "$INDEX_OPTION"
then
gettextln "Index was not unstashed." >&2
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 725f316..6fa0c70 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -203,7 +203,7 @@ test_expect_success 'mergetool skips resolved paths when
rerere is active' '
git reset --hard
'
-test_expect_failure 'conflicted stash sets up rerere' '
+test_expect_success 'conflicted stash sets up rerere' '
git config rerere.enabled true &&
git checkout stash1 &&
echo "Conflicting stash content" >file11 &&
--
1.7.11.1.213.gb567ea5.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
