Re: Expected Behavior?

From: Petr Baudis <pasky@suse.cz>
Date: Nov 9, 2005, 23:42 UTC
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 <junkio@cox.net> said that...

Show 10 quoted lines

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