author | Junio C Hamano <gitster@pobox.com> | |
Thu, 6 Jan 2011 19:33:27 +0000 (11:33 -0800) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Fri, 7 Jan 2011 00:51:43 +0000 (16:51 -0800) | ||
commit | f322b3569024e4325c653d56bb939dc7b062033a | |
tree | bf382ce11f0a9d27ecd42b8d3b029ad41865a370 | tree | snapshot |
parent | 685e9d9145a186a4b2036ecf2be73cc86d99a9b7 | commit | diff |
rerere "remaining"
After "rerere" resolves conflicts by reusing old resolution, there would
be three kinds of paths with conflict in the index:
* paths that have been resolved in the working tree by rerere;
* paths that need further work whose resolution could be recorded;
* paths that need resolving that rerere won't help.
When the user wants a list of paths that need hand-resolving, output from
"rerere status" does not help, as it shows only the second category, but
the paths in the third category still needs work (rerere only makes sense
for regular files that have both our side and their side, and does not
help other kinds of conflicts, e.g. "we modified, they deleted").
The new subcommand "rerere remaining" can be used to show both.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After "rerere" resolves conflicts by reusing old resolution, there would
be three kinds of paths with conflict in the index:
* paths that have been resolved in the working tree by rerere;
* paths that need further work whose resolution could be recorded;
* paths that need resolving that rerere won't help.
When the user wants a list of paths that need hand-resolving, output from
"rerere status" does not help, as it shows only the second category, but
the paths in the third category still needs work (rerere only makes sense
for regular files that have both our side and their side, and does not
help other kinds of conflicts, e.g. "we modified, they deleted").
The new subcommand "rerere remaining" can be used to show both.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/rerere.c | diff | blob | history | |
rerere.c | diff | blob | history |