'read-tree -m head' vs 'read-tree head'

Hello, I see in Linus merge script

	read-tree -m $merge_tree && checkout-cache -f -a && update-cache --refresh

Does this the same as read-tree $merge_tree would do?

	Thomas

The form "git-read-tree <tree>" does not care what the original cache contained and builds the cache from scratch. On the other hand, "git-read-tree -m <tree>" uses what the original cache contained to speed things up in later checkout-cache. That's the official version of difference description.

That said, I've been wondering if "git-read-tree -m <tree>" always does the same thing (but only making the operation afterwards faster) as "git-read-tree <tree>". That is, if there is a valid use case where you would want to use it without "-m" because "-m" does something wrong. If there is no such valid use case probably we should always do "-m" version if we are reading only one tree, practically deprecating "-m" flag to the same status as "-r" flag to git-diff-cache.

However, I have not had time to think things through and have not bugged Linus about it myself.

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

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

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

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.

Hello Junio,

thanks for the bottom line. That explains why Linus uses it in his git-pull-script.

	Thomas