{"thread":{"id":"37421","subject":"mktree: multiple same-named objects","startedAt":"2014-08-27T04:41:57Z","lastAt":"2014-08-27T21:48:33Z","messageCount":6,"participants":["David Turner","Duy Nguyen","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"248379","messageId":"1409114517.13351.6.camel@leckie","threadId":"37421","inReplyTo":null,"subject":"mktree: multiple same-named objects","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-08-27T04:41:57Z","receivedAt":"2014-08-27T04:41:57Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"git mktree seems to allow the creation of a tree object with multiple\nobjects of the same name but different SHAs. This leads to weird\nbehavior later, unsurprisingly. For instance, if there are two tree\nobjects with the same name but different SHAs, the checked out tree will\nbe the union of them (reasonably), but if you do git add $name, some or\nall unmodified files under $name will show up in git status as modified\n-- since they differ from one of the parent trees, presumably.\n\nAnd if different git implementations treat this case differently, then\nit might be possible to make a repo that appears to contain one thing\nwhen viewed with one implementation, but contains a different thing for\na different implementation.\n\nSummary: git mktree ought to forbid this, and possibly there ought to be\nother checks (for instance, when unpacking) to prevent this.\n"},{"id":"248381","messageId":"CACsJy8C+Vg98XjvfSodWLG33mmQOhUrmVKO25EO2MSBTzgttFQ@mail.gmail.com","threadId":"37421","inReplyTo":"1409114517.13351.6.camel@leckie","subject":"Re: mktree: multiple same-named objects","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-08-27T05:01:43Z","receivedAt":"2014-08-27T05:01:43Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Aug 27, 2014 at 11:41 AM, David Turner wrote:\n> Summary: git mktree ought to forbid this, and possibly there ought to be\n> other checks (for instance, when unpacking) to prevent this.\n\nDoes fsck detect this (because we ought to fix fsck first if it does not)?\n-- \nDuy\n"},{"id":"248382","messageId":"20140827051341.GB32141@peff.net","threadId":"37421","inReplyTo":"1409114517.13351.6.camel@leckie","subject":"Re: mktree: multiple same-named objects","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-27T05:13:41Z","receivedAt":"2014-08-27T05:13:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 27, 2014 at 12:41:57AM -0400, David Turner wrote:\n\n> git mktree seems to allow the creation of a tree object with multiple\n> objects of the same name but different SHAs.\n\nYeah, I don't think we do many quality checks there. Ditto for \"git\nhash-object\".\n\nThe latter goes through index_mem, which at least checks that the\nresulting tree is parseable. It does not look like mktree even checks\nthat.\n\n> Summary: git mktree ought to forbid this, and possibly there ought to be\n> other checks (for instance, when unpacking) to prevent this.\n\nThe checks in git-fsck will notice your problem (and many others). I\nthink we should be running them anytime we create an object based on\narbitrary data (including mktree and hash-object). Code paths like \"git\nwrite-tree\" and \"git commit-tree\" are probably OK, as their code should\nfollow the standard (it would not hurt to double-check their output,\nthough there may be a performance implication).\n\nDscho (cc'd) has been looking into this approach; I don't know how far\nhe has gotten.\n\n-Peff\n"},{"id":"248404","messageId":"xmqqk35uezd0.fsf@gitster.dls.corp.google.com","threadId":"37421","inReplyTo":"20140827051341.GB32141@peff.net","subject":"Re: mktree: multiple same-named objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-08-27T15:17:15Z","receivedAt":"2014-08-27T15:17:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Aug 27, 2014 at 12:41:57AM -0400, David Turner wrote:\n>\n>> git mktree seems to allow the creation of a tree object with multiple\n>> objects of the same name but different SHAs.\n>\n> Yeah, I don't think we do many quality checks there. Ditto for \"git\n> hash-object\".\n\nI am somewhat against outright removing the capability to write out\ninvalid objects deliberately from these low level tools, because we\nwould need a way to easily reproduce bugs in end-user facing tools\nby other people who claim to produce Git objects, but I would agree\nthat by default that should be forbidden.\n\nIn other words, two things must happen; improve checks when these\nlow level debugging aid tools are creating objects, and allow\nbypassing these additional checks with \"--experiment\" option or\nsomething.\n"},{"id":"248408","messageId":"20140827162425.GA1432@peff.net","threadId":"37421","inReplyTo":"xmqqk35uezd0.fsf@gitster.dls.corp.google.com","subject":"Re: mktree: multiple same-named objects","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-27T16:24:25Z","receivedAt":"2014-08-27T16:24:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 27, 2014 at 08:17:15AM -0700, Junio C Hamano wrote:\n\n> I am somewhat against outright removing the capability to write out\n> invalid objects deliberately from these low level tools, because we\n> would need a way to easily reproduce bugs in end-user facing tools\n> by other people who claim to produce Git objects, but I would agree\n> that by default that should be forbidden.\n> \n> In other words, two things must happen; improve checks when these\n> low level debugging aid tools are creating objects, and allow\n> bypassing these additional checks with \"--experiment\" option or\n> something.\n\nYeah, definitely. I had imagined it as \"--strict\" and \"--no-strict\",\nwith flipping the default to \"--strict\" at some point (I do not see a\nreason anybody would not want it in normal use, but if we are worried,\nwe can even go slowly on flipping the default).\n\n-Peff\n"},{"id":"248449","messageId":"1409176113.15185.0.camel@leckie","threadId":"37421","inReplyTo":"CACsJy8C+Vg98XjvfSodWLG33mmQOhUrmVKO25EO2MSBTzgttFQ@mail.gmail.com","subject":"Re: mktree: multiple same-named objects","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2014-08-27T21:48:33Z","receivedAt":"2014-08-27T21:48:33Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"On Wed, 2014-08-27 at 12:01 +0700, Duy Nguyen wrote:\n> On Wed, Aug 27, 2014 at 11:41 AM, David Turner wrote:\n> > Summary: git mktree ought to forbid this, and possibly there ought to be\n> > other checks (for instance, when unpacking) to prevent this.\n> \n> Does fsck detect this (because we ought to fix fsck first if it does not)?\n\nYes, it does.\n"}]}