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.
