git mergetool broken when rerere active
- From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
- Date
- Jan 6, 2011, 03:39 UTC
- Message-ID
- <alpine.DEB.1.10.1101052119530.26654@debian>
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