Re: git mergetool broken when rerere active

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 6, 2011, 18:56 UTC
Message-ID: <7vbp3tc142.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.10.1101052119530.26654@debian>

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

Show 13 quoted lines

> When rerere is enabled, git mergetool uses 'git rerere status' to find
> out which files to run the merge tool on. This was introduced in
> bb0a484 (mergetool: Skip autoresolved paths, 2010-08-17). Before that,
> 'git ls-files -u' was used, whether or not rerere was active.
>
> This change caused two problems:
>
>  (1) Before this change, it used to be that case that all conflicts
>      would be resolved and added to the index after running 'git
>      mergetool' without arguments, i.e. on all files. After the
>      change, conflicts of type 'deleted by them' or 'deleted by us'
>      would be ignored, since they are not listed shown by 'git rerere
>      status'.

Good point. We used to say "everything that had conflict after a mergy operation", now we say "everything that rerere attempted resolution but didn't succeed". Missing are paths that rerere didn't even attempt to apply previous resolution at all.

Probably we would need a "git rerere remaining" sobcommand that is similar to status but also includes the "punted" paths.