From: Phil Hord <hordp@cisco.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, Phil Hord <hordp@cisco.com>
Subject: [PATCH 2/2] Clear rerere status during stash conflict
Date: Fri, 6 Jul 2012 12:22:52 -0400 [thread overview]
Message-ID: <1341591772-26251-3-git-send-email-hordp@cisco.com> (raw)
In-Reply-To: <1341591772-26251-1-git-send-email-hordp@cisco.com>
The presence of a GIT_DIR/MERGE_RR file indicates we
were resolving a merge which had rerere candidates for
recording. But the file does not get deleted after
all resolutions are completed. This is ok for most
cases because the file will get replaced when the
next merge happens. But stash apply directly uses
a merge backend, which is not supported by rerere.
The prior rerere state is left behind (in MERGE_RR)
rather than being cleaned up or overwritten as it
would with a normal merge.
This then confuses mergetool who thinks a rerere
operation is in play when it is not.
When we encounter a conflicted stash, ask rerere to
clean up with 'git rerere clear'. This is safe to do
since we know that rerere is not taking part in this
conflict resolution, and any previous unresolved rerere
activity would have prevented us from attempting the
stash apply in the first place.
Change the test for this flaw to expect success.
Signed-off-by: Phil Hord <hordp@cisco.com>
Mentored-by: Junio C Hamano <gitster@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..5bd45ef 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 clear
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 2796c53..99e8c1d 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 'mergetool ignores rerere in git-stash conflicts' '
+test_expect_success 'mergetool ignores rerere in git-stash conflicts' '
git checkout -b stash3 stash1 &&
git config rerere.enabled true &&
echo "Conflicting stash content" >file11 &&
--
1.7.11.1.213.gb567ea5.dirty
prev parent reply other threads:[~2012-07-06 16:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 16:22 [PATCH 0/2] git-stash: clear rerere state on conflict Phil Hord
2012-07-06 16:22 ` [PATCH 1/2] test: mergetool ignores rerere in git-stash Phil Hord
2012-07-06 16:22 ` Phil Hord [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1341591772-26251-3-git-send-email-hordp@cisco.com \
--to=hordp@cisco.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).