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. 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 would be a better match. -Peff