{"thread":{"id":"1708","subject":"Couple of read-tree questions","startedAt":"2005-09-01T04:17:18Z","lastAt":"2005-09-01T15:55:48Z","messageCount":7,"participants":["Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7985","messageId":"Pine.LNX.4.63.0509010009350.23242@iabervon.org","threadId":"1708","inReplyTo":null,"subject":"Couple of read-tree questions","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-01T04:17:18Z","receivedAt":"2005-09-01T04:17:18Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Is there any current use for read-tree with multiple trees without -m or \nequivalent?\n\nWhy does --emu23 use I+H for stage 2, rather than just I? Wouldn't this \njust reintroduce removed files?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7986","messageId":"7vll2h4bc8.fsf@assigned-by-dhcp.cox.net","threadId":"1708","inReplyTo":"Pine.LNX.4.63.0509010009350.23242@iabervon.org","subject":"Re: Couple of read-tree questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-01T05:16:07Z","receivedAt":"2005-09-01T05:16:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Is there any current use for read-tree with multiple trees without -m or \n> equivalent?\n\nI did not know it even allowed multiple trees without -m, but\nyou are right. It does not seem to complain.\n\nI have never thought about using multiple trees without -m, and\nI do not remember hearing any plan nor purpose of using it to do\nsomething interesting from Linus. I think its allowing multiple\ntrees without -m is simply a bug.\n\n> Why does --emu23 use I+H for stage 2, rather than just I? Wouldn't this \n> just reintroduce removed files?\n\nThey are not \"removed files\", at least in the original context.\n\nThe original intention was that git was supposed to work without\nhaving _any_ files in the working tree. The reason why\nmulti-tree read-tree has so many special cases that says \"must\nmatch *if* work file exists\", is that not having a corresponding\nworking file was supposed to be equivalent to having the file\nchecked out *and* unmodified.\n\nThat assumption and design goal was partially broken at around\nthe beginning of June when we started touching working tree\nduring a merge. Until that timeframe, we did not touch (nor\neven look at) files in the working tree during the merge, mainly\ndue to the desire of performing the merge operation entirely in\nthe cache (which was the name of \"index file\" back then).\n\nI do not think anybody currently uses --emu23. I did it because\nit has a potential of making the two-tree fast forward (which is\nused in \"git checkout\" to switch between branches) easier to\nmanage when the working tree is dirty than doing straight\ntwo-tree merge, but that is just a theoretical potential never\ntested in the field. Frankly, I do not mind, and I do not think\nanybody else minds, too much if you need to break or remove\nemu23 if that would make your code clean-up and redoing\nread-tree easier.\n"},{"id":"7987","messageId":"7vzmqx1gi4.fsf@assigned-by-dhcp.cox.net","threadId":"1708","inReplyTo":"7vll2h4bc8.fsf@assigned-by-dhcp.cox.net","subject":"Re: Couple of read-tree questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-01T05:52:51Z","receivedAt":"2005-09-01T05:52:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> Why does --emu23 use I+H for stage 2, rather than just I? Wouldn't this \n>> just reintroduce removed files?\n>\n> They are not \"removed files\", at least in the original context.\n>\n> The original intention was...\n\nGmane turns out to be better remembering things than my faulty\nmemory. The thread beginning here is a good summary of the\nthinking behind the current design:\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/4737\n"},{"id":"7988","messageId":"Pine.LNX.4.63.0509010138370.23242@iabervon.org","threadId":"1708","inReplyTo":"7vll2h4bc8.fsf@assigned-by-dhcp.cox.net","subject":"Re: Couple of read-tree questions","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-01T06:16:17Z","receivedAt":"2005-09-01T06:16:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 31 Aug 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Is there any current use for read-tree with multiple trees without -m or \n> > equivalent?\n> \n> I did not know it even allowed multiple trees without -m, but\n> you are right. It does not seem to complain.\n> \n> I have never thought about using multiple trees without -m, and\n> I do not remember hearing any plan nor purpose of using it to do\n> something interesting from Linus. I think its allowing multiple\n> trees without -m is simply a bug.\n\nI guess it was probably that its behavior was obvious and didn't require \nany extra code. It still follows entirely from one tree without -m, but it \nmight be worth prohibiting unless someone has a reason to do it \nintentionally.\n\n> > Why does --emu23 use I+H for stage 2, rather than just I? Wouldn't this \n> > just reintroduce removed files?\n> \n> They are not \"removed files\", at least in the original context.\n> \n> The original intention was that git was supposed to work without\n> having _any_ files in the working tree. The reason why\n> multi-tree read-tree has so many special cases that says \"must\n> match *if* work file exists\", is that not having a corresponding\n> working file was supposed to be equivalent to having the file\n> checked out *and* unmodified.\n\nBut they'd not only be missing from the working tree but also from the \n(pre-read-tree) index, which should only happen, assuming the index came \nfrom \"read-tree H\", if they were subsequently removed from the index. I'd \nunderstand treating index entries for files missing from the working tree \nas up to date.\n\n(The thread you mention seems to say that we accept entries being missing \nfrom the index as if they were unchanged, but I don't see a good reason \nfor this; you'd be dealing with the full set in the index for the merge, \neven if you don't have a populated working tree)\n\n> I do not think anybody currently uses --emu23. I did it because\n> it has a potential of making the two-tree fast forward (which is\n> used in \"git checkout\" to switch between branches) easier to\n> manage when the working tree is dirty than doing straight\n> two-tree merge, but that is just a theoretical potential never\n> tested in the field. Frankly, I do not mind, and I do not think\n> anybody else minds, too much if you need to break or remove\n> emu23 if that would make your code clean-up and redoing\n> read-tree easier.\n\nI should have asked sooner, then. :) There's a bunch of clutter to get it \nto work that I can remove if it's not actually necessary.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7989","messageId":"7vvf1l1env.fsf@assigned-by-dhcp.cox.net","threadId":"1708","inReplyTo":"Pine.LNX.4.63.0509010138370.23242@iabervon.org","subject":"Re: Couple of read-tree questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-01T06:32:36Z","receivedAt":"2005-09-01T06:32:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> (The thread you mention seems to say that we accept entries being missing \n> from the index as if they were unchanged, but I don't see a good reason \n> for this; you'd be dealing with the full set in the index for the merge, \n> even if you don't have a populated working tree)\n\nYou are correct. I was wondering myself why *both* of us\nthought (or Linus *seemed* to be agreeing, at least to me) what I\nwas referring to as I+H made any sense while re-reaing the\nthread.\n\n> I should have asked sooner, then. :) There's a bunch of clutter to get it \n> to work that I can remove if it's not actually necessary.\n\nYeah, removal of dead code! Go wild, please.\n"},{"id":"7990","messageId":"7vpsrt1cwc.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1708","inReplyTo":"7vvf1l1env.fsf@assigned-by-dhcp.cox.net","subject":"Reworked read-tree.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-01T07:10:43Z","receivedAt":"2005-09-01T07:10:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel, I do not know what your current status is, but I think\nyou need something like this.\n\nI was scratching my head figuring out why it passes all the t/\ntests but couldn't do a simple 'git-read-tree HEAD'.\n\n---\ndiff --git a/tree.c b/tree.c\n--- a/tree.c\n+++ b/tree.c\n@@ -224,10 +224,12 @@ struct tree *parse_tree_indirect(const u\n \t\tif (obj->type == tree_type)\n \t\t\treturn (struct tree *) obj;\n \t\telse if (obj->type == commit_type)\n-\t\t\treturn ((struct commit *) obj)->tree;\n+\t\t\tobj = (struct object *)(((struct commit *) obj)->tree);\n \t\telse if (obj->type == tag_type)\n-\t\t\tobj = ((struct tag *) obj)->tagged;\n+\t\t\tobj = deref_tag(obj);\n \t\telse\n \t\t\treturn NULL;\n+\t\tif (!obj->parsed)\n+\t\t\tparse_object(obj->sha1);\n \t} while (1);\n }\n"},{"id":"7993","messageId":"Pine.LNX.4.63.0509011143350.23242@iabervon.org","threadId":"1708","inReplyTo":"7vpsrt1cwc.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: Reworked read-tree.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-01T15:55:48Z","receivedAt":"2005-09-01T15:55:48Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 1 Sep 2005, Junio C Hamano wrote:\n\n> Daniel, I do not know what your current status is, but I think\n> you need something like this.\n\nYup, I forgot to actually test that functionality.\n\n> ---\n> diff --git a/tree.c b/tree.c\n> --- a/tree.c\n> +++ b/tree.c\n> @@ -224,10 +224,12 @@ struct tree *parse_tree_indirect(const u\n> \t\tif (obj->type == tree_type)\n> \t\t\treturn (struct tree *) obj;\n> \t\telse if (obj->type == commit_type)\n> -\t\t\treturn ((struct commit *) obj)->tree;\n> +\t\t\tobj = (struct object *)(((struct commit *) obj)->tree);\n\nobj = &((struct commit *) obj)->tree->object;\n\nMultiple sequential casts always bother me, and we do actually have a \nfield for this.\n\n> \t\telse if (obj->type == tag_type)\n> -\t\t\tobj = ((struct tag *) obj)->tagged;\n> +\t\t\tobj = deref_tag(obj);\n\nShouldn't be necessary (once you've got the parse_object below); we're \nalready in a loop dereferencing things.\n\n> \t\telse\n> \t\t\treturn NULL;\n> +\t\tif (!obj->parsed)\n> +\t\t\tparse_object(obj->sha1);\n> \t} while (1);\n> }\n> \n> \n"}]}