On Mon, Jun 25, 2012 at 12:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Phil Hord <phil.hord@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html