From: Junio C Hamano Date: Thu, 03 Nov 2005 08:02:10 GMT Subject: Re: Three-way merge with the index as one way Message-ID: <7vy846ma65.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20051103003423.GH1431@pasky.or.cz> Petr Baudis writes: > 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.