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.