Re: [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

>     But what it really is forced to do is more of a 4-way merge; a good
>     chunk of its annoying complexity is based around this (undocumented
>     and unfortunate) reality.  It derives from what I consider a simple
>     design flaw.

Yes, and it does not help that it wants to write into the filesystem
while it performs the outermost merges.

In the ideal world, we should

 - ask unpack_trees() to do "read-tree -m" without "-u";

 - do all the merge-recursive computations in-core and prepare the
   resulting index, while keeping the current index intact;

 - compare the current in-core index and the resulting in-core
   index, and notice the paths that need to be added, updated or
   removed in the working tree, and ensure that there is no loss of
   information when the change is reflected to the working tree,
   e.g. the result wants to create a file where the working tree
   currently has a directory with non-expendable contents in it, the
   result wants to remove a file where the working tree file has
   local modification, etc.; and then finally

 - carry out the working tree update to make it match what the
   resulting in-core index says it should look like.