I am trying to do a checkout from github, and I got this error message:

[user@arch ~]$ git clone --recursive https://github.com/simsong/tcpflow.git
Cloning into 'tcpflow'...
The authenticity of host 'github.com (' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,' (RSA) to the list of known hosts.
remote: Counting objects: 4190, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 4190 (delta 21), reused 29 (delta 12), pack-reused 4146
Receiving objects: 100% (4190/4190), 50.27 MiB | 2.21 MiB/s, done.
Resolving deltas: 100% (2954/2954), done.
Submodule 'src/be13_api' (https://github.com/simsong/be13_api.git) registered for path 'src/be13_api'
Submodule 'src/dfxml' (https://github.com/simsong/dfxml.git) registered for path 'src/dfxml'
Submodule 'src/http-parser' (https://github.com/nodejs/http-parser.git) registered for path 'src/http-parser'
Cloning into '/home/user/tcpflow/src/be13_api'...
remote: Counting objects: 1203, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 1203 (delta 2), reused 5 (delta 1), pack-reused 1194
Receiving objects: 100% (1203/1203), 477.47 KiB | 1.96 MiB/s, done.
Resolving deltas: 100% (821/821), done.
Cloning into '/home/user/tcpflow/src/dfxml'...
remote: Counting objects: 1929, done.
remote: Total 1929 (delta 0), reused 0 (delta 0), pack-reused 1929
Receiving objects: 100% (1929/1929), 572.09 KiB | 2.89 MiB/s, done.
Resolving deltas: 100% (1294/1294), done.
Cloning into '/home/user/tcpflow/src/http-parser'...
remote: Counting objects: 1487, done.
remote: Total 1487 (delta 0), reused 0 (delta 0), pack-reused 1487
Receiving objects: 100% (1487/1487), 667.24 KiB | 2.46 MiB/s, done.
Resolving deltas: 100% (916/916), done.
Submodule path 'src/be13_api': checked out 'c81521d768bb78499c069fcd7c47adc8eee0350c'
Submodule path 'src/dfxml': checked out 'c31224626cf5f6678d42cbcfbfcd4e6191c9a864'
error: Server does not allow request for unadvertised object 5bbcdc5df9d01b521e8da011bab0da70bdec3653
Fetched in submodule path 'src/http-parser', but it did not contain 5bbcdc5df9d01b521e8da011bab0da70bdec3653. Direct fetching of that commit failed.
[user@arch ~]$

So I'm the maintainer of these repos. The src/http-parser is a fork of another repo, and the maintainers of that repo have consistently not accepted my pull requests (with no reasons given) to add a few auto-generated files to the .gitignore file. But I don't think that's the issue here.

  • I've tried the same command and there was no error. Do you still have an issue? Btw in my case it checked out different commit: Submodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394' – ge0rdi Aug 12 '17 at 18:17
  • The issue is gone. I think that it means that the submodule reference was for a checkout that doesn't exist. But Im' not sure. – vy32 Aug 13 '17 at 19:35
  • As a note for others confused but this message, it can arise if you update a submodule, update a parent module to the new commit, and never push the new commit in the submodule. Then, of course, you'll have trouble checking out a commit that doesn't exist on the submodule's remote! – Patrick Sanan Oct 17 '19 at 10:49
  • The problem seems to be that I updated the submodule, updated the parent repo, pushed the parent repo, but didn't push the submodule. So literally, the parent repo referenced a commit that wasn't in the submodule's repo on github. – vy32 Oct 18 '19 at 0:33

jgit - What is git's advertised refs? - Stack Overflow:

During a fetch, the server can list references that it has and that the client may wish to fetch. These are the advertised references.

  • It looks like you cannot directly get any single specific commit from the server, only refs (i.e. branches and tags). Or rather, that Github servers are configured to disallow such requests.
  • So, if you want to get a specific commit with --depth, it must be at most <depth>-1 commits away from the fetched ref (which is the branch/tag specified in the submodule's metadata)

    Typically, folks advise to just set depth to some number reasonably large but still much smaller than the total number of commit in the repo -- like 50 or 100. E.g. 50 is what Travis uses when doing the initial clone for the project.

If you aren't updating the submodule with --depth, failing to find the commit would mean any of:

  • the submodule's tree is in "shallow" state and the above applies (only possible when it was previously updated with --depth or its entry in .gitmodules has shallow = true)
  • the commit is not on the branch that the submodule is using
  • the commit is not in the submodule's repo at all:
    • either someone made a mistake,
    • or it was once there but was deleted by a forced push

For the record, in your specific case, it was the last case: commit 5bbcdc5df9d01b521e8da011bab0da70bdec3653 is not in the https://github.com/simsong/http-parser.git repo at all.

  • What is depth? – vy32 Jan 18 '18 at 2:15
  • @vy32 added info for the case when you aren't updating with --depth. – ivan_pozdeev Jan 20 '18 at 13:27
  • "it was once there but was deleted by a forced push" - is there any recourse in this situation? – skolsuper Apr 30 '19 at 1:20
  • 1
    @skolsuper choose a different commit to retrieve. E.g. if that was a submodule, switch it to a different commit in the superproject. – ivan_pozdeev Apr 30 '19 at 2:06

One way to get access to an unadvertized object is to sync. Then a submodule update should work, like:

git submodule sync --recursive
git submodule update
  • 1
    +1 for simplicity. for me git submodule update failed on another submodule, but when I applied these two lines to all my submodules in the correct order, it finally worked. – Bizhan Sep 3 '19 at 12:15
  • 2
    For potentially large super-projects, you'd be advised to actually carry out $ git submodule sync --recursive; git submodule update OR, if it is just after cloning a remote , just $ git submodule update --init --recursive. This will effectively traverse your project file-tree from /project/root/ down, according to what's in /project/root/.gitmodules. Much more at $ git submodule --help... – Cbhihe Oct 18 '19 at 12:50
  • Thanks @Cbhihe I'll edit the answer to include the --recursive flag. – carver Oct 18 '19 at 13:35
  • In my case, someone had actually pushed a submodule with a detached head, which caused this error. – JOATMON Mar 3 '20 at 21:29

This can happen when you are pointing to submodule commit that has been removed through a history re-write or squash. The best you can do is:

  • First get a clear picture of what your team has been doing so you know what it should look like.
  • Update your local with a git pull and then find the closest commit that works with your branch (it may be the latest) and then add that to your parent repo. e.g. something like:
parent-repo$ git fetch
parent-repo$ cd submodule-a
submodule-a$ git pull
submodule-a$ git checkout best-commit-according-to-team-and-your-branch
submodule-a$ cd ../
parent-repo$ git status
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
        modified:  submodule-a (modified content)
git add submodule-a
git commit -m "updated submodule-a reference"

Once you are happy it is correct and your team agrees you can push it up and the error should go away.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.