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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 3, 2005, 21:21 UTC
Message-ID: <7v8xw5ctrc.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051103202125.GK1431@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 6 quoted lines

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