On Wed, 2017-01-11 at 07:53 -0500, Jeff King wrote: > On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote: > > > Why does git cat-file -t $sha:foo, where foo is a submodule, not work? > > Because "cat-file" is about inspecting items in the object database, and > typically the submodule commit is not present in the superproject's > database. So we cannot know its type. You can infer what it _should_ be > from the surrounding tree, but you cannot actually do the object lookup. > > Likewise, "git cat-file -t $sha1:Makefile" is not just telling you that > we found a 100644 entry in the tree, so we expect a blob. It's resolving > to a sha1, and then checking the type of that sha1 in the database. It > _should_ be a blob, but if it isn't, then cat-file is the tool that > should tell you that it is not. > > > git rev-parse $sha:foo works. > > Right. Because that command is about resolving a name to a sha1, which > we can do even without the object. > > > By "why", I mean "would anyone complain if I fixed it?" FWIW, I think > > -p should just return the submodule's sha. > > I'm not sure if I'm complaining or not. I can't immediately think of > something that would be horribly broken. But it really feels like you > are using the wrong tool, and patching the tool to handle this case will > probably lead to weird cognitive dissonance down the road.
OK, this makes sense to me. I tried cat-file because that is the tool I was familiar with, but that doesn't mean that it was the right thing to do. > Maybe it would help to describe your use case more fully. If what you > care about is the presumed type based on the surrounding tree, then > maybe: > > git --literal-pathspecs ls-tree $sha -- foo That (minus --literal-pathspecs, which does not exist in the version of git I happen to be using) is fine for my purposes. Thanks.
