From: Petr Baudis Date: Wed, 09 Nov 2005 23:42:12 GMT Subject: Re: Expected Behavior? Message-ID: <20051109234212.GJ30496@pasky.or.cz> In-Reply-To: <7virv18kc3.fsf@assigned-by-dhcp.cox.net> Dear diary, on Thu, Nov 10, 2005 at 12:36:44AM CET, I got a letter where Junio C Hamano said that... > Fredrik's using his own mergeFile is defensible from both > performance and implementation point of view. After the rename > processing stage, he already extracted enough information from > trees involved, and there is no reason for him to be preparing > three stages in the index file with that information (which is > cumbersome because there is no interface to populate the higher > stage directly using git-update-index --- you have to first > create temporary tree objects and ask git-read-tree -m to do so) > and asking git-merge-index to call git-merge-one-file. If you > read git-merge-one-file, it is not a rocket science. I'm not arguing against mergeFile but rather git-merge-one-file (and by implication cg-Xmergefile), actually. My point is - couldn't be mergeFile generalized a bit or padded with suitable interface to be usable as git-merge-one-file's drop-in replacement? > While we _may_ want to keep the logic that decides what to do in > various cases across these three implementations, at least for me, it > does not particularly feel disturbing, especially when there are good > reasons. I'm not sure I follow you here - what exactly does not feel disturbing and what good reasons are there for whatever they are? :-) -- 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.