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

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

[Thomas Glanzmann]

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

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

[Junio C Hamano]

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.

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

[Petr Baudis]

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

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

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

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

[Junio C Hamano]

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

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

[Thomas Glanzmann]

Hello Junio,

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

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

	Thomas