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

23

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

vy32
источник
Я пробовал ту же команду, и не было ошибки. У вас все еще есть проблема? Кстати, в моем случае это проверил другой коммит:Submodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394'
ge0rdi
Вопрос исчез. Я думаю, это означает, что ссылка на субмодуль предназначена для проверки, которая не существует. Но я не уверен.
vy32
Как примечание для других, которые были сбиты с толку, но это сообщение может появиться, если вы обновите субмодуль, обновите родительский модуль до нового коммита и никогда не вставляете новый коммит в субмодуле. Тогда, конечно, у вас будут проблемы с проверкой коммита, которого нет на пульте субмодуля!
Патрик Санан
Кажется, проблема в том, что я обновил субмодуль, обновил родительский репо, выдвинул родительский репо, но не подтолкнул субмодуль. В буквальном смысле, родительское репо ссылается на коммит, которого нет в репозитории подмодуля на github.
vy32

Ответы:

8

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
1
@skolsuper выберите другой коммит для извлечения. Например, если это был подмодуль, переключите его на другой коммит в суперпроекте.
ivan_pozdeev
3

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

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