That makes a lot sense. It would be nice, IMHO, if everything listed in ls-tree were able to be cat-file'd, but I understand why it's not. Thanks so much for the direction!
On Thursday, June 8, 2017 at 4:20:56 PM UTC-4, Philip Oakley wrote: > > 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 <javascript:> > *To:* Git for human beings <javascript:> > *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 > <https://gitlab.com/gitlab-org/gitlab-ce/issues/26403> 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 <https://gitlab.com/butlermd/parent> and Child > <https://gitlab.com/butlermd/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+...@googlegroups.com <javascript:>. > 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.
