Re: MERGE_RR droppings

Phil Hord [off-list ref] writes:

git mergetool decides to use rerere-remaining based on the existence
of the .git/MERGE_RR file:

    if test -e "$GIT_DIR/MERGE_RR"

This is correct, I would probably write it with "test -f" if I were
writing this line today, though.  After you commit to conclude the
merge, the MERGE_RR marker should disappear.  Isn't it happening for
you?

On Mon, Jun 18, 2012 at 7:05 PM, Junio C Hamano [off-list ref] wrote:

Phil Hord [off-list ref] writes:

quoted

git mergetool decides to use rerere-remaining based on the existence
of the .git/MERGE_RR file:

    if test -e "$GIT_DIR/MERGE_RR"

This is correct, I would probably write it with "test -f" if I were
writing this line today, though.  After you commit to conclude the
merge, the MERGE_RR marker should disappear.  Isn't it happening for
you?

I was able to isolate this today to cherry-pick.

When I successfully cherry-pick a change (no conflicts, no merges), I
get a .git/MERGE_RR file left over.  After this happens, git-mergetool
will think there are no unresolved conflicts unless git (or I) first
removes the .git/MERGE_RR.

Maybe this only causes trouble for 'git stash apply' since it does not
employ rerere machinery, or because it takes some other code path
which does not begin by removing .git/MERGE_RR.

A naive fix would be to remove MERGE_RR at the conclusion of
'stash-apply', but I do not think that is the right place for it to
go.

Suggestions?

Phil