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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 3, 2005, 08:02 UTC
Message-ID: <7vy846ma65.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051103003423.GH1431@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 5 quoted lines

> One approach is to take the working tree, construct a tree object from
> it and then run the regular three-way merge on that. But that is a waste
> of time and pollutes the database with nonsensical objects. The
> advantage is that I can reuse the per-file merge resolution script
> without any changes.

For a large tree, constructing a full tree just to merge a couple of potentially conflicting paths might turn out be a waste of time, but I suspect that is something you could optimize later. 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. Right now git-am takes an e-mail patch and when it runs all the way it creates a commit, but the core logic that applies patch and falls back to 3-way could be separated out for your application. Then you could: (1) 'git diff HEAD' before tree-warp to preserve the user changes, (2) clean up the working tree to match HEAD, (3) warp to the other tree, and (4) fed the user change perserved to git-am core logic. That might give you something near optimum.

About "nonsensical" objects, I am not so sure how nonsensical those objects you would record from the working tree (intermediate state) are. If you find two trees match on a path that has changed in the working tree, there won't be any conflict on that paths so it is like the user did an extra git-update-index on that path when no merge or warp is involved, from object database pollution POV; I do not personally think that is such a bad thing.