Re: 'read-tree -m head' vs 'read-tree head'

From: Junio C Hamano <junkio@cox.net>
Date: May 4, 2005, 06:54 UTC
Message-ID: <7vr7gnpjkq.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050503213444.GD15995@pasky.ji.cz>

>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:

PB> Dear diary, on Tue, May 03, 2005 at 09:13:40PM CEST, I got a letter PB> where Junio C Hamano <junkio@cox.net> told me that...

>> That said, I've been wondering ... if there
>> is a valid use case where you would want to use it without "-m"
>> because "-m" does something wrong...

PB> -m fails when your cache file is missing/corrupted. Not that it cannot PB> be fixed, just remember to fix it if you are going to do what you PB> described.

Missing case seems to be handled fine. It spits out a message from error() on a corrupt cache, but does not choke on it and creates a valid cache in the end.

I just found out why we *do* need non -m version. The -m version refuses to work on an unmerged cache, which is the right thing to do. If you try a merge, and if you do not like the result, you can throw the index away and start from scratch with non -m version. Of course "rm .git/index" would work just fine as well.

Another reason we may want to avoid -m version is that it takes a long time to read the cache on a large project, but I think a read-tree almost always is followed by a checkout-cache in a typical use case, and -m version significantly improves the performance of the latter.

    read-tree -m $other; checkout-cache -f -a
    read-tree    $other; checkout-cache -f -a

A not so scientific benchmark of reading one commit in a work tree based on a commit several steps away (this is linux-2.6 tree so the index file is 1.6MB), run on my machine with a slow disk, does the former in 12 seconds and the latter in about 18 seconds. Comparison between the following is more drastic.

    read-tree -m $other; update-cache --refresh
    read-tree    $other; update-cache --refresh

The version with -m wins by factor of ten.

So Thomas, here is my conclusion:

    Normally "read-tree -m" is the preferred form from
    performance point of view, especially on a large project.
    The only case you need to use "read-tree" without -m is when
    the cache contains conflicting merge results and you want to
    start from scratch.