Web lists-archives.com

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




On Fri, Nov 24, 2017 at 7:29 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Elijah Newren <newren@xxxxxxxxx> 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.

I had another email I had been composing to try to argue for changing
merge-recursive.c's design to the above, assuming I could get the time
to work on it.  Nice to see that I'm not crazy, and that I apparently
don't need to do much convincing.  :-)