"Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> 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);
