>>>>> "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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed May 04 16:57:42 2005
This archive was generated by hypermail 2.1.8 : 2005-05-04 16:57:42 EST