Re: [git-users] git cat-file on a submodule results in fatal error

2017-06-09 Thread Michael Butler 
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  
> *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
>
> 16 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 .
> 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.

Re: [git-users] git cat-file on a submodule results in fatal error

2017-06-08 Thread Philip Oakley 
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
16 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.