Re: MERGE_RR droppings

From: Phil Hord <phil.hord@gmail.com>
Date: Jun 25, 2012, 18:36 UTC
Message-ID: <CABURp0rBRnFjJaXO3BUYWcyXEAsLZeEv05z-hMi8aW9SPTCPqA@mail.gmail.com>
In-Reply-To: <7v8vfk2pby.fsf@alter.siamese.dyndns.org>

On Mon, Jun 18, 2012 at 7:05 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> Phil Hord <phil.hord@gmail.com> 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?

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