Cosa significa il messaggio di errore git "Il server non consente la richiesta di oggetto non pubblicizzato"?

Sto provando a fare un checkout da github e ho ricevuto questo messaggio di errore:

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

Quindi sono il manutentore di questi repository. Src / http-parser è un fork di un altro repository e i manutentori di quel repository non hanno costantemente accettato le mie richieste pull (senza motivazioni fornite) per aggiungere alcuni file generati automaticamente al .gitignorefile. Ma non penso che questo sia il problema qui.

git github

— vy32
fonte

Ho provato lo stesso comando e non si sono verificati errori. Hai ancora un problema? A proposito, nel mio caso è stato verificato un commit diverso:Submodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394'

— ge0rdi,

Il problema è andato. Penso che ciò significhi che il riferimento al sottomodulo era per un checkout che non esiste. Ma non sono sicuro.

— vy32,

Come nota per gli altri confusi ma questo messaggio, può sorgere se si aggiorna un sottomodulo, si aggiorna un modulo genitore al nuovo commit e non si inserisce mai il nuovo commit nel sottomodulo. Quindi, ovviamente, avrai problemi a verificare un commit che non esiste sul telecomando del sottomodulo!

— Patrick Sanan,

Il problema sembra essere che ho aggiornato il sottomodulo, aggiornato il repository principale, inviato il repository principale, ma non il push del sottomodulo. Quindi, letteralmente, il repository principale ha fatto riferimento a un commit che non era nel repository del sottomodulo su github.

— vy32,

Risposte:

jgit - Quali sono i ref pubblicizzati da git? - StackTranslate.it :

Durante un recupero, il server può elencare i riferimenti che ha e che il client potrebbe desiderare di recuperare. Questi sono i riferimenti pubblicizzati.

Sembra che non sia possibile ottenere direttamente un singolo commit specifico dal server, solo ref (es. Rami e tag). O meglio, che i server Github sono configurati per non consentire tali richieste.
Quindi, se si desidera ottenere un commit specifico con --depth, deve essere al massimo <depth>-1commit rispetto al ref recuperato (che è il ramo / tag specificato nei metadati del sottomodulo)

_{In genere, le persone consigliano di impostare solo depthun numero ragionevolmente grande ma comunque molto più piccolo del numero totale di commit nel repository, come 50o 100. Ad esempio, 50viene utilizzato da Travis quando si esegue il clone iniziale per il progetto.}

Se non si aggiorna il sottomodulo con --depth, non riuscire a trovare il commit significherebbe:

l'albero del sottomodulo è nello stato "superficiale" e vale quanto sopra (possibile solo quando è stato precedentemente aggiornato con --deptho la sua voce .gitmoduleshashallow = true )
il commit non si trova sul ramo utilizzato dal sottomodulo
il commit non è affatto nel repository del sottomodulo:
- o qualcuno ha fatto un errore,
- o era una volta lì ma è stato eliminato da una spinta forzata

Per la cronaca, nel tuo caso specifico, è stato l'ultimo caso: commit 5bbcdc5df9d01b521e8da011bab0da70bdec3653non è affatto nel https://github.com/simsong/http-parser.gitrepository.

— ivan_pozdeev
fonte

Che cosa è depth?

— vy32,

@ vy32 ha aggiunto informazioni per il caso quando non si aggiorna --depth.

— ivan_pozdeev,

"era una volta lì ma è stato eliminato da una spinta forzata" - c'è qualche ricorso in questa situazione?

— skolsuper

@skolsuper scegli un commit diverso da recuperare. Ad esempio, se si trattava di un sottomodulo, passalo a un commit diverso nel superproject.

— ivan_pozdeev,

Un modo per ottenere l'accesso a un oggetto non pubblicizzato è la sincronizzazione. Quindi un aggiornamento del sottomodulo dovrebbe funzionare, come:

git submodule sync --recursive
git submodule update

— intagliatore
fonte

+1 per semplicità. per me git submodule updatenon è riuscito su un altro sottomodulo, ma quando ho applicato queste due righe a tutti i miei sottomoduli nell'ordine corretto , alla fine ha funzionato.

— Bizhan,

Per i super-progetti potenzialmente di grandi dimensioni, ti consigliamo di eseguire effettivamente $ git submodule sync --recursive; git submodule updateOR, se è solo dopo aver clonato un telecomando, giusto $ git submodule update --init --recursive. Questo attraverserà efficacemente l'albero dei file del progetto dal /project/root/basso, in base a cosa c'è dentro /project/root/.gitmodules. Molto di più a $ git submodule --help...

— Cbhihe,

Grazie @Cbhihe, modificherò la risposta per includere la --recursivebandiera.

— intagliatore