☰

Что означает сообщение об ошибке git «Сервер не разрешает запрос на необъявленный объект»?

tag-icon • tag-icon git github
Что означает сообщение об ошибке git «Сервер не разрешает запрос на необъявленный объект»?

Я пытаюсь выполнить проверку с github и получаю следующее сообщение об ошибке:

[user@arch ~]$ git clone --recursive https://github.com/simsong/tcpflow.git
Cloning into 'tcpflow'...
The authenticity of host 'github.com (192.30.253.113)' 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,192.30.253.113' (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 ~]$

Итак, я поддерживаю эти репозитории. Src/http-parser — это ответвление другого репозитория, и поддерживающие этого репозитория постоянно не принимают мои запросы на извлечение (без указания причин) на добавление нескольких автоматически сгенерированных файлов в файл .gitignore. Но я не думаю, что это проблема.

решение1

jgit - Что такое объявленные ссылки git? - Stack Overflow:

Во время выборки сервер может перечислить ссылки, которые у него есть и которые клиент может пожелать получить. Это объявленные ссылки.

  • Это выглядит каквы не можете напрямую получить какой-либо конкретный коммит с сервера, только ссылки (т. е. ветви и теги).Или, скорее, серверы Github настроены на запрет таких запросов.

  • Так,если вы хотите получить определенный коммит с--depth, он должен находиться не более чем <depth>-1в коммитах от извлеченной ссылки(это ветвь/тег, указанный в метаданных подмодуля)

    Обычно советуют просто установить depthнекоторое число, достаточно большое, но все же намного меньше общего числа коммитов в репозитории — например, 50или 100. Например, 50это то, что использует Трэвис при выполнении первоначального клонирования проекта.

Если вы не обновляете подмодуль с помощью --depth, невозможность найти коммит будет означать одно из следующего:

  • дерево подмодуля находится в «поверхностном» состоянии, и вышеизложенное применимо (возможно только в том случае, если оно было ранее обновлено с помощью --depthилиего запись в .gitmodulesимеетshallow = true)
  • коммит не находится на ветке, которую использует подмодуль
  • коммит вообще отсутствует в репозитории подмодуля:
    • либо кто-то допустил ошибку,
    • или он когда-то был там, но был удален принудительно

Для справки, в вашем конкретном случае это был последний случай: коммит вообще 5bbcdc5df9d01b521e8da011bab0da70bdec3653отсутствует в репозитории.https://github.com/simsong/http-parser.git

решение2

Один из способов получить доступ к необъявленному объекту — синхронизация. Тогда должно сработать обновление подмодуля, например:

git submodule sync --recursive
git submodule update

решение3

Это может произойти, когда вы указываете на коммит подмодуля, который был удален через переписывание истории или сжатие. Лучшее, что вы можете сделать, это:

  • Сначала получите четкое представление о том, чем занимается ваша команда, чтобы знать, как это должно выглядеть.
  • Обновите свой локальный репозиторий с помощью git pull, а затем найдите ближайший коммит, который работает с вашей веткой (он может быть последним), а затем добавьте его в родительский репозиторий. Например, что-то вроде:
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"

Как только вы убедитесь, что все правильно, и ваша команда с этим согласна, вы можете перенести изменения, и ошибка должна исчезнуть.

решение4

У меня это обычно происходит, когда я отправляю родительский git-репозиторий обратно на github, не отправляя обратно подмодуль, который я изменил и закоммитил, но не отправил обратно.

Связанный контент