{"thread":{"id":"44852","subject":"git cat-file on a submodule","startedAt":"2017-01-11T00:11:48Z","lastAt":"2017-01-11T18:57:00Z","messageCount":5,"participants":["David Turner","Stefan Beller","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"309192","messageId":"1484093500.17967.6.camel@frank","threadId":"44852","inReplyTo":null,"subject":"git cat-file on a submodule","fromName":"David Turner","fromEmail":"novalis@novalis.org","sentAt":"2017-01-11T00:11:40Z","receivedAt":"2017-01-11T00:11:48Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"Why does git cat-file -t $sha:foo, where foo is a submodule, not work? \n\ngit rev-parse $sha:foo works.  \n\nBy \"why\", I mean \"would anyone complain if I fixed it?\"  FWIW, I think\n-p should just return the submodule's sha.\n\n\n\n"},{"id":"309193","messageId":"CAGZ79kbb8b=jLiwJAE7ktq-wYKce-152__aA3bU_uBnV1pbXqg@mail.gmail.com","threadId":"44852","inReplyTo":"1484093500.17967.6.camel@frank","subject":"Re: git cat-file on a submodule","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-11T00:25:34Z","receivedAt":"2017-01-11T00:25:41Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jan 10, 2017 at 4:11 PM, David Turner <novalis@novalis.org> wrote:\n> Why does git cat-file -t $sha:foo, where foo is a submodule, not work?\n>\n> git rev-parse $sha:foo works.\n>\n> By \"why\", I mean \"would anyone complain if I fixed it?\"\n\n$ git log -- builtin/cat-file.c |grep -i -e gitlink -e submodule\n$ # no result\n\nI think nobody cared so far. Go for it!\n\n> FWIW, I think\n> -p should just return the submodule's sha.\n\nThat sounds right as the sha1 is also printed for the tree already, i.e.\nin Gerrit you can get the submodules via\n$ git cat-file -p HEAD:plugins/\n100644 blob c6bb7f182440d6ab860bbcfadc9901b0d94d1ee3 BUCK\n160000 commit 9b163e113de9f3a49219a02d388f7f46ea2559d3\ncommit-message-length-validator\n160000 commit 69b8f9f413ce83a71593a4068a3b8e81f684cbad cookbook-plugin\n160000 commit 7b41f3a413b46140b050ae5324cbbcdd467d2b3a download-commands\n160000 commit 3acc14d10d26678eae6489038fe0d4dad644a9b4 hooks\n160000 commit c5123d6a5604cc740d6f42485235c0d3ec141c4e replication\n160000 commit 3f3d572e9618f268b19cc54856deee4c96180e4c reviewnotes\n160000 commit 3ca1167edda713f4bfdcecd9c0e2626797d7027f singleusergroup\n\n\"commit <sha1>\" is the correct answer already :)\n\nThanks,\nStefan\n"},{"id":"309210","messageId":"20170111125330.3skwxdleoooacts6@sigill.intra.peff.net","threadId":"44852","inReplyTo":"1484093500.17967.6.camel@frank","subject":"Re: git cat-file on a submodule","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-11T12:53:30Z","receivedAt":"2017-01-11T12:53:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote:\n\n> Why does git cat-file -t $sha:foo, where foo is a submodule, not work?\n\nBecause \"cat-file\" is about inspecting items in the object database, and\ntypically the submodule commit is not present in the superproject's\ndatabase. So we cannot know its type. You can infer what it _should_ be\nfrom the surrounding tree, but you cannot actually do the object lookup.\n\nLikewise, \"git cat-file -t $sha1:Makefile\" is not just telling you that\nwe found a 100644 entry in the tree, so we expect a blob. It's resolving\nto a sha1, and then checking the type of that sha1 in the database. It\n_should_ be a blob, but if it isn't, then cat-file is the tool that\nshould tell you that it is not.\n\n> git rev-parse $sha:foo works.\n\nRight. Because that command is about resolving a name to a sha1, which\nwe can do even without the object.\n\n> By \"why\", I mean \"would anyone complain if I fixed it?\"  FWIW, I think\n> -p should just return the submodule's sha.\n\nI'm not sure if I'm complaining or not. I can't immediately think of\nsomething that would be horribly broken. But it really feels like you\nare using the wrong tool, and patching the tool to handle this case will\nprobably lead to weird cognitive dissonance down the road.\n\nMaybe it would help to describe your use case more fully. If what you\ncare about is the presumed type based on the surrounding tree, then\nmaybe:\n\n  git --literal-pathspecs ls-tree $sha -- foo\n\nwould be a better match.\n\n-Peff\n"},{"id":"309223","messageId":"1484158902.11251.3.camel@frank","threadId":"44852","inReplyTo":"20170111125330.3skwxdleoooacts6@sigill.intra.peff.net","subject":"Re: git cat-file on a submodule","fromName":"David Turner","fromEmail":"novalis@novalis.org","sentAt":"2017-01-11T18:21:42Z","receivedAt":"2017-01-11T18:22:04Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"On Wed, 2017-01-11 at 07:53 -0500, Jeff King wrote:\n> On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote:\n> \n> > Why does git cat-file -t $sha:foo, where foo is a submodule, not work?\n> \n> Because \"cat-file\" is about inspecting items in the object database, and\n> typically the submodule commit is not present in the superproject's\n> database. So we cannot know its type. You can infer what it _should_ be\n> from the surrounding tree, but you cannot actually do the object lookup.\n> \n> Likewise, \"git cat-file -t $sha1:Makefile\" is not just telling you that\n> we found a 100644 entry in the tree, so we expect a blob. It's resolving\n> to a sha1, and then checking the type of that sha1 in the database. It\n> _should_ be a blob, but if it isn't, then cat-file is the tool that\n> should tell you that it is not.\n> \n> > git rev-parse $sha:foo works.\n> \n> Right. Because that command is about resolving a name to a sha1, which\n> we can do even without the object.\n> \n> > By \"why\", I mean \"would anyone complain if I fixed it?\"  FWIW, I think\n> > -p should just return the submodule's sha.\n> \n> I'm not sure if I'm complaining or not. I can't immediately think of\n> something that would be horribly broken. But it really feels like you\n> are using the wrong tool, and patching the tool to handle this case will\n> probably lead to weird cognitive dissonance down the road.\n\nOK, this makes sense to me.  I tried cat-file because that is the tool I\nwas familiar with, but that doesn't mean that it was the right thing to\ndo.\n\n> Maybe it would help to describe your use case more fully. If what you\n> care about is the presumed type based on the surrounding tree, then\n> maybe:\n> \n>   git --literal-pathspecs ls-tree $sha -- foo\n\nThat (minus --literal-pathspecs, which does not exist in the version of\ngit I happen to be using) is fine for my purposes.  Thanks.\n\n"},{"id":"309226","messageId":"xmqqshopo26j.fsf@gitster.mtv.corp.google.com","threadId":"44852","inReplyTo":"20170111125330.3skwxdleoooacts6@sigill.intra.peff.net","subject":"Re: git cat-file on a submodule","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-11T18:56:52Z","receivedAt":"2017-01-11T18:57:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote:\n>\n>> Why does git cat-file -t $sha:foo, where foo is a submodule, not work?\n> ...\n> I'm not sure if I'm complaining or not. I can't immediately think of\n> something that would be horribly broken. But it really feels like you\n> are using the wrong tool, and patching the tool to handle this case will\n> probably lead to weird cognitive dissonance down the road.\n\n\"git cat-file [any option] $sha\" should fail and complain for any\n$sha that does not name an object that exists in the object database\nof the repository it is working on.  \n\nSo I'd complain if the first example command quoted above from\nDavid's mail stopped failing when the commit bound at 'foo' in the\ntop-level treeish $sha (i.e. a commit in the submodule) does not\nexist in the top-level repository's object database.\n\n> Maybe it would help to describe your use case more fully. If what you\n> care about is the presumed type based on the surrounding tree, then\n> maybe:\n>\n>   git --literal-pathspecs ls-tree $sha -- foo\n>\n> would be a better match.\n\nYup.\n"}]}