git mergetool broken when rerere active

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

Hi,

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'. Previously, git mergetool would ask whether to pick the
     modified file or to delete the file.

 (2) When running mergetool again after resolving some (or all)
     conflicts, so that some of the files have already been added to
     the index, mergetool will now print something like

     file1: file does not need merging
     Continue merging other unresolved paths (y/n) ?

     Before the change, any files that were already added to the index
     would just be skipped, without mergetool asking the user whether
     to continue.

I would like to have both the original properties in (1) and (2) back,
i.e. being ready for commit once 'git mergetool' has been successfully
completed, and having it ignore any files that have already been added
to the index.

I was reading the original thread [1], but I didn't quite understand
why just enabling rerere.autoupdate would not solve the problem. Maybe
it was just that the goal was a solution that works even with
rerere.autoupdate disabled? Can we fix it in some way by combining the
output of 'git rerere status' and 'git ls-files -u'?


Regards,
Martin

[1] http://thread.gmane.org/gmane.comp.version-control.git/153420