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 = g...@gitlab.com: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 git-users+unsubscr...@googlegroups.com.
  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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to