Co oznacza komunikat o błędzie git „Serwer nie zezwala na żądanie niezadeklarowanego obiektu”?

23

Próbuję zrobić kasę z github, i otrzymałem ten komunikat o błędzie:

[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 ~]$

Więc jestem opiekunem tych repozytoriów. Parser src / http jest rozwidleniem innego repozytorium, a opiekunowie tego repozytorium konsekwentnie nie akceptują moich żądań ściągnięcia (bez podania powodów) dodania do pliku kilku automatycznie wygenerowanych plików .gitignore. Ale nie sądzę, że o to tu chodzi.

vy32
źródło
Próbowałem tego samego polecenia i nie wystąpił błąd. Czy nadal masz problem? Btw w moim przypadku sprawdził inne zatwierdzenie:Submodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394'
ge0rdi
Problem zniknął. Myślę, że to oznacza, że ​​odwołanie do podmodułu dotyczyło kasy, która nie istnieje. Ale nie jestem pewien.
vy32
Jako uwaga dla innych zdezorientowanych, ale ten komunikat może się pojawić, jeśli zaktualizujesz podmoduł, zaktualizujesz moduł nadrzędny do nowego zatwierdzenia i nigdy nie wypchniesz nowego zatwierdzenia w podmodule. Wtedy oczywiście będziesz miał problem ze sprawdzeniem zatwierdzenia, które nie istnieje na pilocie podmodułu!
Patrick Sanan
Problem polega na tym, że zaktualizowałem podmoduł, zaktualizowałem repozytorium nadrzędne, wypchnąłem repozytorium nadrzędne, ale nie wypchnąłem tego podmodułu. Zatem dosłownie repozytorium nadrzędne odwoływało się do zatwierdzenia, którego nie było w repozytorium podmodułu na github.
vy32

Odpowiedzi:

8

jgit - Co to jest reklamowane referencje git? - Przepełnienie stosu :

Podczas pobierania serwer może wyświetlić listę referencji, które posiada i które klient może chcieć pobrać. Są to reklamowane referencje.

  • Wygląda na to, że nie możesz bezpośrednio pobrać żadnego konkretnego zatwierdzenia z serwera, tylko referencje (tj. Gałęzie i tagi). A raczej, że serwery Github są skonfigurowane tak, aby nie zezwalać na takie żądania.
  • Tak więc, jeśli chcesz uzyskać określone zatwierdzenie --depth, musi to być co najwyżej <depth>-1commits z dala od pobranego odwołania (który jest odgałęzieniem / znacznikiem określonym w metadanych submodułu)

    Zazwyczaj ludzie radzą po prostu ustawić depthna pewną liczbę rozsądnie dużą, ale wciąż znacznie mniejszą niż całkowita liczba zatwierdzeń w repozytorium - 50lub 100. Np. 50To, czego Travis używa podczas pierwszego klonowania projektu.

Jeśli nie aktualizujesz podmodułu za pomocą --depth, nie można znaleźć zatwierdzenia oznaczałoby:

  • drzewo submodułu jest w „płytkim” stanie i powyższe ma zastosowanie (możliwe tylko wtedy, gdy zostało wcześniej zaktualizowane --depthlub jego wpis .gitmodulesmashallow = true )
  • zatwierdzenie nie znajduje się w gałęzi, z której korzysta podmoduł
  • zatwierdzenia w ogóle nie ma w repozytorium podmodułu:
    • albo ktoś popełnił błąd,
    • lub był kiedyś, ale został usunięty przez wymuszone wypchnięcie

Dla przypomnienia, w twoim konkretnym przypadku był to ostatni przypadek: zatwierdzenia 5bbcdc5df9d01b521e8da011bab0da70bdec3653w ogóle nie ma w https://github.com/simsong/http-parser.gitrepozytorium.

ivan_pozdeev
źródło
Co to jest depth?
vy32
@ vy32 dodał informacje o przypadku, gdy nie aktualizujesz za pomocą --depth.
ivan_pozdeev
„kiedyś tam był, ale został usunięty przez wymuszone wypchnięcie” - czy w tej sytuacji jest jakaś ucieczka?
skolsuper 30.04.19
1
@skolsuper wybierz inne zatwierdzenie do pobrania. Np. Jeśli był to submoduł, przełącz go na inny zatwierdzenie w superprojekcie.
ivan_pozdeev
3

Jednym ze sposobów uzyskania dostępu do nieadaptowanego obiektu jest synchronizacja. Następnie aktualizacja podmodułu powinna działać, na przykład:

git submodule sync --recursive
git submodule update
rzeźbiarz
źródło
1
+1 za prostotę. dla mnie git submodule updatenie powiodło się na innym submodule, ale kiedy zastosowałem te dwa wiersze do wszystkich moich submodułów w odpowiedniej kolejności , w końcu zadziałało.
Bizhan
2
W przypadku potencjalnie dużych superprojektów zaleca się przeprowadzenie operacji $ git submodule sync --recursive; git submodule updateLUB, jeśli nastąpi to tuż po sklonowaniu pilota $ git submodule update --init --recursive. Spowoduje to efektywne przejście od drzewa plików projektu od /project/root/dołu, zgodnie z tym, co jest w środku /project/root/.gitmodules. Znacznie więcej w $ git submodule --help...
Cbhihe,
Dzięki @Cbhihe zredaguję odpowiedź, aby dołączyć --recursiveflagę.
carver