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. :-)
