"Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> writes:
> I just had "an interesting case" for a merge with conflicts:
> The merge re-introduced a file that had been renamed (say old one is "bla",
> and the new one is "foo").
> After merging the changes from bla into foo, I added foo, trying to remove
> bla:
>> git add foo
>> git rm bla
> bla: needs merge
> rm 'bla'
Yeah, I think I've known about this for a long time. We have an
internal call to "update-index --refresh" before starting to remove,
because we need to know which path is up-to-date wrt the index, and
the machinery for refreshing the index by default gives the "needs
merge" message. We never bothered to squelch it.
Perhaps this one-liner would be a sufficient fix.
builtin/rm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 2eacda42b4..19ce95a901 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -273,7 +273,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
parse_pathspec(&pathspec, 0,
PATHSPEC_PREFER_CWD,
prefix, argv);
- refresh_index(&the_index, REFRESH_QUIET, &pathspec, NULL, NULL);
+ refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED, &pathspec,
NULL, NULL);
seen = xcalloc(pathspec.nr, 1);
