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