From: Phil Hord <phil.hord@gmail.com>
Date: Mon, 25 Jun 2012 18:36:39 GMT
Subject: Re: MERGE_RR droppings
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:
> 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