Re: Three-way merge with the index as one way

Petr Baudis [off-list ref] writes:

quoted

git-am 3-way fallback logic constructs a sparse
temporary tree and uses it for running regular 3-way, and you
may be able to do something similar.

I'm confused now - if the tree is sparse, how does git-read-tree -m know
that the missing files from the other tree are not deletes?

The git-am 3-way fallback works like this:

    - the patch did not apply to our current head cleanly.

    - however, we have all the original blobs, recorded on
      'index xxxxxxx..xxxxxxx' line of the patch.

    - construct a temporary tree T0 that has only paths affected
      by that patch, with the original blobs.

    - apply the patch to T0 to construct another temporary tree
      T1.

    - 3-way merge our current head and T1, pretending as if T0
      is our common ancestor.  I.e. "read-tree -m -u T0 HEAD T1"

The paths that did not change by the patch (in your case, the
paths without local modification before tree-warp) are not
present in either T0 or T1, so the 3-way merge in the last step
would see that our current head added those paths while T0->T1
transition kept their absense intact --- which results in
added-in-one-side-only.

I think the problem you are solving would be solved by what I
suggested in the earlier message, but probably always doing that
may not be the optimum solution.

    - the working tree (and index) is derived from HEAD, but may
      not match HEAD (local modifications).

    - you want to tree-warp to T1, doing an equivalent of
      "read-tree -m -u HEAD T1" but preserving the local
      modifications.

You would want a merge between INDEX and T1 using HEAD as the
common ancestor (INDEX is a tree that your user would get if all
the local modification in the working tree were registered with
update-index and then git-write-tree were run).

	 INDEX
        /
    HEAD
        \
         T1

Two-tree form of read-tree -m -u should work as long as
differences between HEAD and INDEX do not interfere with
HEAD->T1 transition.  So you probably would first want to try
"read-tree -m -u HEAD T1", and use the 3-way fallback I
described earlier when it fails?

But if they don't match, you'll get superfluous blobs for the original
index versions which are almost certain to go away.

Another way of putting it is that I would not particularly worry
about those dangling blobs and trees -- that's what we have 'git
prune' for.