git cat-file on a submodule

git cat-file on a submodule

[David Turner]

Why does git cat-file -t $sha:foo, where foo is a submodule, not work? 

git rev-parse $sha:foo works.  

By "why", I mean "would anyone complain if I fixed it?"  FWIW, I think
-p should just return the submodule's sha.

Re: git cat-file on a submodule

[Stefan Beller]

On Tue, Jan 10, 2017 at 4:11 PM, David Turner <novalis@novalis.org> wrote:
> Why does git cat-file -t $sha:foo, where foo is a submodule, not work?
>
> git rev-parse $sha:foo works.
>
> By "why", I mean "would anyone complain if I fixed it?"

$ git log -- builtin/cat-file.c |grep -i -e gitlink -e submodule
$ # no result

I think nobody cared so far. Go for it!

> FWIW, I think
> -p should just return the submodule's sha.

That sounds right as the sha1 is also printed for the tree already, i.e.
in Gerrit you can get the submodules via
$ git cat-file -p HEAD:plugins/
100644 blob c6bb7f182440d6ab860bbcfadc9901b0d94d1ee3 BUCK
160000 commit 9b163e113de9f3a49219a02d388f7f46ea2559d3
commit-message-length-validator
160000 commit 69b8f9f413ce83a71593a4068a3b8e81f684cbad cookbook-plugin
160000 commit 7b41f3a413b46140b050ae5324cbbcdd467d2b3a download-commands
160000 commit 3acc14d10d26678eae6489038fe0d4dad644a9b4 hooks
160000 commit c5123d6a5604cc740d6f42485235c0d3ec141c4e replication
160000 commit 3f3d572e9618f268b19cc54856deee4c96180e4c reviewnotes
160000 commit 3ca1167edda713f4bfdcecd9c0e2626797d7027f singleusergroup

"commit <sha1>" is the correct answer already :)

Thanks,
Stefan

Re: git cat-file on a submodule

[Jeff King]

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

Re: git cat-file on a submodule

[David Turner]

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.

Re: git cat-file on a submodule

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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?
> ...
> 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.

"git cat-file [any option] $sha" should fail and complain for any
$sha that does not name an object that exists in the object database
of the repository it is working on.  

So I'd complain if the first example command quoted above from
David's mail stopped failing when the commit bound at 'foo' in the
top-level treeish $sha (i.e. a commit in the submodule) does not
exist in the top-level repository's object database.

> 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.

Yup.