Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes: > 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. -- 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