From: Petr Baudis Date: Thu, 03 Nov 2005 20:21:25 GMT Subject: Re: Three-way merge with the index as one way Message-ID: <20051103202125.GK1431@pasky.or.cz> In-Reply-To: <7vy846ma65.fsf@assigned-by-dhcp.cox.net> Dear diary, on Thu, Nov 03, 2005 at 09:02:10AM CET, I got a letter where Junio C Hamano told me that... > 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? > 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, At this point I get nervous since there is a potential for data loss when something goes wrong at this point (e.g. system crash). I'm not saying there are no places like that in Cogito now, but I generally try to avoid them whenever possible. > (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. But if they don't match, you'll get superfluous blobs for the original index versions which are almost certain to go away. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.