{"thread":{"id":"456","subject":"'read-tree -m head' vs 'read-tree head'","startedAt":"2005-05-03T12:49:35Z","lastAt":"2005-05-04T07:01:48Z","messageCount":5,"participants":["Thomas Glanzmann","Junio C Hamano","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2465","messageId":"20050503124935.GT25004@cip.informatik.uni-erlangen.de","threadId":"456","inReplyTo":null,"subject":"'read-tree -m head' vs 'read-tree head'","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-03T12:49:35Z","receivedAt":"2005-05-03T12:49:35Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\nI see in Linus merge script\n\n\tread-tree -m $merge_tree && checkout-cache -f -a && update-cache --refresh\n\nDoes this the same as read-tree $merge_tree would do?\n\n\tThomas\n"},{"id":"2500","messageId":"7vbr7sw2aj.fsf@assigned-by-dhcp.cox.net","threadId":"456","inReplyTo":"20050503124935.GT25004@cip.informatik.uni-erlangen.de","subject":"Re: 'read-tree -m head' vs 'read-tree head'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-03T19:13:40Z","receivedAt":"2005-05-03T19:13:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The form \"git-read-tree \" does not care what the original\ncache contained and builds the cache from scratch. On the other\nhand, \"git-read-tree -m \" uses what the original cache\ncontained to speed things up in later checkout-cache. That's\nthe official version of difference description.\n\nThat said, I've been wondering if \"git-read-tree -m \"\nalways does the same thing (but only making the operation\nafterwards faster) as \"git-read-tree \". That is, if there\nis a valid use case where you would want to use it without \"-m\"\nbecause \"-m\" does something wrong. If there is no such valid\nuse case probably we should always do \"-m\" version if we are\nreading only one tree, practically deprecating \"-m\" flag to the\nsame status as \"-r\" flag to git-diff-cache.\n\nHowever, I have not had time to think things through and have\nnot bugged Linus about it myself.\n\n\n"},{"id":"2530","messageId":"20050503213444.GD15995@pasky.ji.cz","threadId":"456","inReplyTo":"7vbr7sw2aj.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'read-tree -m head' vs 'read-tree head'","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-03T21:34:44Z","receivedAt":"2005-05-03T21:34:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, May 03, 2005 at 09:13:40PM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> That said, I've been wondering if \"git-read-tree -m \"\n> always does the same thing (but only making the operation\n> afterwards faster) as \"git-read-tree \". That is, if there\n> is a valid use case where you would want to use it without \"-m\"\n> because \"-m\" does something wrong. If there is no such valid\n> use case probably we should always do \"-m\" version if we are\n> reading only one tree, practically deprecating \"-m\" flag to the\n> same status as \"-r\" flag to git-diff-cache.\n> \n> However, I have not had time to think things through and have\n> not bugged Linus about it myself.\n\n-m fails when your cache file is missing/corrupted. Not that it cannot\nbe fixed, just remember to fix it if you are going to do what you\ndescribed.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"2562","messageId":"7vr7gnpjkq.fsf@assigned-by-dhcp.cox.net","threadId":"456","inReplyTo":"20050503213444.GD15995@pasky.ji.cz","subject":"Re: 'read-tree -m head' vs 'read-tree head'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-04T06:54:29Z","receivedAt":"2005-05-04T06:54:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"PB\" == Petr Baudis writes:\n\nPB> Dear diary, on Tue, May 03, 2005 at 09:13:40PM CEST, I got a letter\nPB> where Junio C Hamano told me that...\n\n>> That said, I've been wondering ... if there\n>> is a valid use case where you would want to use it without \"-m\"\n>> because \"-m\" does something wrong...\n\nPB> -m fails when your cache file is missing/corrupted. Not that it cannot\nPB> be fixed, just remember to fix it if you are going to do what you\nPB> described.\n\nMissing case seems to be handled fine. It spits out a message\nfrom error() on a corrupt cache, but does not choke on it and\ncreates a valid cache in the end.\n\nI just found out why we *do* need non -m version. The -m version\nrefuses to work on an unmerged cache, which is the right thing\nto do. If you try a merge, and if you do not like the result,\nyou can throw the index away and start from scratch with non -m\nversion. Of course \"rm .git/index\" would work just fine as\nwell.\n\nAnother reason we may want to avoid -m version is that it takes\na long time to read the cache on a large project, but I think a\nread-tree almost always is followed by a checkout-cache in a\ntypical use case, and -m version significantly improves the\nperformance of the latter.\n\n read-tree -m $other; checkout-cache -f -a\n read-tree $other; checkout-cache -f -a\n\nA not so scientific benchmark of reading one commit in a work\ntree based on a commit several steps away (this is linux-2.6\ntree so the index file is 1.6MB), run on my machine with a slow\ndisk, does the former in 12 seconds and the latter in about 18\nseconds. Comparison between the following is more drastic.\n\n read-tree -m $other; update-cache --refresh\n read-tree $other; update-cache --refresh\n\nThe version with -m wins by factor of ten.\n\nSo Thomas, here is my conclusion:\n\n Normally \"read-tree -m\" is the preferred form from\n performance point of view, especially on a large project.\n The only case you need to use \"read-tree\" without -m is when\n the cache contains conflicting merge results and you want to\n start from scratch.\n\n"},{"id":"2563","messageId":"20050504070148.GF18380@cip.informatik.uni-erlangen.de","threadId":"456","inReplyTo":"7vr7gnpjkq.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'read-tree -m head' vs 'read-tree head'","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-04T07:01:48Z","receivedAt":"2005-05-04T07:01:48Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello Junio,\n\n> Normally \"read-tree -m\" is the preferred form from\n> performance point of view, especially on a large project.\n> The only case you need to use \"read-tree\" without -m is when\n> the cache contains conflicting merge results and you want to\n> start from scratch.\n\nthanks for the bottom line. That explains why Linus uses it in his\ngit-pull-script.\n\n\tThomas\n"}]}