# 'read-tree -m head' vs 'read-tree head' 5 messages from 2005-05-03 to 2005-05-04. Participants: Thomas Glanzmann, Junio C Hamano, Petr Baudis. Thread: https://gitlist.dev/t/456 ## Thomas Glanzmann, 2005-05-03 12:49 Subject: 'read-tree -m head' vs 'read-tree head' Message-ID: <20050503124935.GT25004@cip.informatik.uni-erlangen.de> URL: https://gitlist.dev/e/20050503124935.GT25004%40cip.informatik.uni-erlangen.de ``` 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 ``` ## Junio C Hamano, 2005-05-03 19:13 Subject: Re: 'read-tree -m head' vs 'read-tree head' Message-ID: <7vbr7sw2aj.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbr7sw2aj.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050503124935.GT25004@cip.informatik.uni-erlangen.de> ``` The form "git-read-tree " does not care what the original cache contained and builds the cache from scratch. On the other hand, "git-read-tree -m " 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 " always does the same thing (but only making the operation afterwards faster) as "git-read-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. ``` ## Petr Baudis, 2005-05-03 21:34 Subject: Re: 'read-tree -m head' vs 'read-tree head' Message-ID: <20050503213444.GD15995@pasky.ji.cz> URL: https://gitlist.dev/e/20050503213444.GD15995%40pasky.ji.cz In-Reply-To: <7vbr7sw2aj.fsf@assigned-by-dhcp.cox.net> ``` Dear diary, on Tue, May 03, 2005 at 09:13:40PM CEST, I got a letter where Junio C Hamano told me that... > That said, I've been wondering if "git-read-tree -m " > always does the same thing (but only making the operation > afterwards faster) as "git-read-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 ``` ## Junio C Hamano, 2005-05-04 06:54 Subject: Re: 'read-tree -m head' vs 'read-tree head' Message-ID: <7vr7gnpjkq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7gnpjkq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050503213444.GD15995@pasky.ji.cz> ``` >>>>> "PB" == Petr Baudis writes: PB> Dear diary, on Tue, May 03, 2005 at 09:13:40PM CEST, I got a letter PB> where Junio C Hamano 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. ``` ## Thomas Glanzmann, 2005-05-04 07:01 Subject: Re: 'read-tree -m head' vs 'read-tree head' Message-ID: <20050504070148.GF18380@cip.informatik.uni-erlangen.de> URL: https://gitlist.dev/e/20050504070148.GF18380%40cip.informatik.uni-erlangen.de In-Reply-To: <7vr7gnpjkq.fsf@assigned-by-dhcp.cox.net> ``` 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 ```