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
--
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