Re: MERGE_RR droppings

From: David Aguilar <davvid@gmail.com>
Date: Jun 26, 2012, 04:31 UTC
Message-ID: <CAJDDKr7Hj4f-Gww4j89kppR8g1vzmhmydsFnG0ecjzL5WrRP4g@mail.gmail.com>
In-Reply-To: <7vwr2vfc1c.fsf@alter.siamese.dyndns.org>

On Mon, Jun 25, 2012 at 12:04 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 25 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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?
>
> Oops.  It actually does not happen for _me_. An empty MERGE_RR is
> left in the working tree after rerere has dealt with the conflicts.
> There seems to be only three codepaths that explicitly remove
> MERGE_RR that is stale:
>
>  - (obviously) "rerere clear"
>  - "git reset"
>  - "git checkout otherbranch"
>
> Perhaps mergetool should consider a missing MERGE_RR and an empty
> one the same way?

Would that test look (roughly) like this?

    if test -f "$GIT_DIR/MERGE_RR" && test -n "$(cat "$GIT_DIR/MERGE_RR")"
    then
	files=$(git rerere remaining)
    else
	files=$(git ls-files -u | sed -e 's/^[^	]*	//' | sort -u)
    fi
    ...

If so I'll throw together a patch.

-- 
David