I've just had a quick skim of the question.
The reply that the submodule is recoreded as if it is a commit within a tree is
correct. The mode (IIRC) should be 16000 as well (can be googled for.
What is wrong is the assumption that you can dig beyond that point. The
returned sha1 is for a commit that is from some other repo - the submodule
repo. You will need to go find that repo before you could access that sha1, (as
I understand it).
There is some ongoing development on submodules so I may be a bit outdated.
HTH
Philip
----- Original Message -----
From: Michael Butler
To: Git for human beings
Sent: Thursday, June 08, 2017 5:56 PM
Subject: [git-users] git cat-file on a submodule results in fatal error
I'm trying to integrate a third-party code review tool with an instance of
GitLab. In attempting to do so, I found that reviews weren't being created
properly because GitLab's API was returning a 500 error. I dug into it and
discovered that the call that was returning 500 was a call to display the
contents of a submodule. Turns out, I'm not the only one with this problem. The
original poster on that issue had logs with this line:
fatal: git cat-file: could not get object info
I don't have access to my company's instance of GitLab, so I couldn't check
the logs on our side. But what I could do was create a pair of test repos on
GitLab.com so that they were publicly visible. The repos are very simple.
Parent and Child. Child is just a blank readme and Parent is just a parent for
Child. I was able to reproduce the same issue with the API. Next, I decided to
see what would happen if I git cat-file the files myself. So I did this:
$ git --version
git version 2.11.0 (Apple Git-81)
$ git ls-tree 9dd77c0670df70e4d90d1b8d62bd04c322f66adb
100644 blob 97dbd82a65e6f87e228ffebdb6e1a130a41cb222 .gitmodules
160000 commit 155bac3293f79229a105fb95677f83a9de6b57ac child
$ git cat-file blob 97dbd82a65e6f87e228ffebdb6e1a130a41cb222
[submodule "child"]
path = child
url = [email protected]:butlermd/child.git
$ git cat-file blob 155bac3293f79229a105fb95677f83a9de6b57ac
fatal: git cat-file 155bac3293f79229a105fb95677f83a9de6b57ac: bad file
$ git cat-file commit 155bac3293f79229a105fb95677f83a9de6b57ac
fatal: git cat-file 155bac3293f79229a105fb95677f83a9de6b57ac: bad file
$ git cat-file -t 155bac3293f79229a105fb95677f83a9de6b57ac
fatal: git cat-file: could not get object info
I used ls-tree to view the SHAs for the files in my commit and then used that
SHA for child to try to cat-file it. Right off the bat, I noticed from my
ls-tree that the type of child wasn't blob, but commit. I thought maybe GitLab
was assuming it was blob and so it was choking on the error. But as you can
see, I tried it with commit as well, the type given by the results of ls-tree,
and got the same result. Finally, I tried to get the type from cat-file, and
got a fatal error that matches the one posted in the original GitLab issue. I
don't include it here, but I also tried using git show and got similar errors
about bad objects.
So, that's my admittedly long-winded explanation. It appears to either be a
bug in git itself, or there's a totally different approach needed for
submodules that I (and more importantly, GitLab) am not aware of.
--
You received this message because you are subscribed to the Google Groups
"Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
