]> git.ipfire.org Git - thirdparty/git.git/commit - merge-recursive.c
merge-recursive: ignore_case shouldn't reject intentional removals
authorElijah Newren <newren@gmail.com>
Fri, 24 Nov 2017 19:59:01 +0000 (11:59 -0800)
committerJunio C Hamano <gitster@pobox.com>
Mon, 27 Nov 2017 00:51:05 +0000 (09:51 +0900)
commit4cba2b0108dbf4d5653a4c4d3208b02c6bc415b7
tree8a44f282e3565bf2fe47f6914efbc3bd2b639011
parent7d22aec681f7656e6f30ef9e3fc92b17d9abc3a3
merge-recursive: ignore_case shouldn't reject intentional removals

In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
2014-05-01), it was observed that removing files could be problematic on
case insensitive file systems, because we could end up removing files
that differed in case only rather than deleting the intended file --
something that happened when files were renamed on one branch in a way
that differed only in case.  To avoid that problem, that commit added
logic to avoid removing files other than the one intended, rejecting the
removal if the files differed only in case.

Unfortunately, the logic it used didn't fully implement that condition as
stated above; instead it merely checked that a case-insensitive lookup of
the file that was requested resulted in finding a file in the index at
stage 0, not that the file found in the index actually differed in case.
Alternatively, one could view the implementation as making an implicit
assumption that the file we actually wanted to remove would never appear
in the index with a stage of 0, and thus that if we found a file with our
lookup, that it had to be a different file (but different in case only).

The net result of this implementation is that it can ignore more requests
than it should, leaving a file around in the working copy that should
have been removed.  Make sure that the file found in the index actually
differs in case before silently ignoring the request to remove the file.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive.c