Что означает сообщение об ошибке 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файл несколько автоматически сгенерированных файлов . Но я не думаю, что это проблема здесь.

git github

— vy32
источник

Я пробовал ту же команду, и не было ошибки. У вас все еще есть проблема? Кстати, в моем случае это проверил другой коммит:Submodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394'

— ge0rdi

Вопрос исчез. Я думаю, это означает, что ссылка на субмодуль предназначена для проверки, которая не существует. Но я не уверен.

— vy32

Как примечание для других, которые были сбиты с толку, но это сообщение может появиться, если вы обновите субмодуль, обновите родительский модуль до нового коммита и никогда не вставляете новый коммит в субмодуле. Тогда, конечно, у вас будут проблемы с проверкой коммита, которого нет на пульте субмодуля!

— Патрик Санан

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

— vy32

Ответы:

jgit - Что такое рекламируемые git реферы? - Переполнение стека :

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

Похоже, вы не можете напрямую получить какой-либо конкретный коммит с сервера, только ссылки (то есть ветки и теги). Или, скорее, что серверы Github настроены на запрет таких запросов.
Итак, если вы хотите получить конкретный коммит с --depth, он должен быть максимально <depth>-1удален от извлеченного ref (который является веткой / тегом, указанным в метаданных подмодуля)

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

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

дерево подмодуля находится в "мелком" состоянии, и вышеизложенное применимо (возможно только тогда, когда оно было ранее обновлено с помощью --depthили его запись в .gitmoduleshasshallow = true )
коммит не находится на ветке, которую использует подмодуль
фиксация вообще отсутствует в репо подмодуля:
- либо кто-то допустил ошибку,
- или он когда-то был там, но был удален принудительным нажатием

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

— ivan_pozdeev
источник

Что такое depth?

— vy32

@ vy32 добавлена информация для случая, когда вы не обновляете с помощью --depth.

— ivan_pozdeev

«это было когда-то там, но было удалено принудительным толчком» - есть ли выход в этой ситуации?

— skolsuper

@skolsuper выберите другой коммит для извлечения. Например, если это был подмодуль, переключите его на другой коммит в суперпроекте.

— ivan_pozdeev

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

git submodule sync --recursive
git submodule update

— резчик
источник

+1 для простоты. для меня git submodule updateпроизошел сбой на другом подмодуле, но когда я применил эти две строки ко всем моим подмодулям в правильном порядке , это, наконец, сработало.

— Бижан

Для потенциально больших суперпроектов, вам бы посоветовали выполнить $ git submodule sync --recursive; git submodule updateИЛИ, если это только после клонирования удаленного, просто $ git submodule update --init --recursive. Это будет эффективно обходить дерево файлов вашего проекта /project/root/снизу, в соответствии с тем, что находится внутри /project/root/.gitmodules. Намного больше в $ git submodule --help...

— Cbhihe

Спасибо @Cbhihe Я отредактирую ответ, чтобы включить --recursiveфлаг.

— резчик