Cosa significa "upload-pack: not our ref" quando si prelevano i ref di Git tramite --tags?

In uno dei miei progetti, i build di Travis non riescono prima che uno qualsiasi dei miei sistemi di build o codice possa essere raggiunto, non appena il mio script di build tenta di recuperare tutti i tag Git con git fetch --tags:

`` git fetch --tags --verbose
POST git-upload-pack (350 bytes)
POST git-upload-pack (788 bytes)
POST git-upload-pack (797 bytes)
From https://github.com/ELLIOTTCABLE/bs-sedlex
 = [up to date]      fix-ci        -> origin/fix-ci
 * [new tag]         sedlex-1.99.2 -> sedlex-1.99.2
 * [new tag]         v1.99.3       -> v1.99.3
...
 * [new tag]         v20.0.0-pre.2 -> v20.0.0-pre.2
Fetching submodule ppx-sedlex
POST git-upload-pack (122 bytes)
From https://github.com/ELLIOTTCABLE/ppx-sedlex
 = [up to date]      develop       -> origin/develop
 = [up to date]      master        -> origin/master
...
 = [up to date]      v20.0.0-pre.2 -> v20.0.0-pre.2
POST git-upload-pack (4 bytes)
POST git-upload-pack (69 bytes)
POST git-upload-pack (586 bytes)
fatal: remote error: upload-pack: not our ref 0f509703fcd43ff4324d721a39220153bab49d4a

Ciò è particolarmente confuso, poiché né il repository principale bs-sedlex, né il sottomodulo git ppx-sedlex, hanno alcun commit che inizia come 0f5097...; Non ho idea da dove provenga questo SHA. Questo errore si verifica solo sui lavoratori Linux , e non riesco a capire perché - git fetch --tagssu quello stesso repository funziona sui macOS Travis-worker, sulla mia macchina macOS e su un Ubuntu Vagrant box mi sono girato per eseguire il debug.

Che cosa significa l'errore "fatale: remoto: upload-pack: non nostro riferimento"; e come posso aggirarlo? Non sono nemmeno sicuro da dove iniziare a eseguire il debug di questo errore, in quanto si verifica specificamente sui lavoratori Travis.

(È improbabile che sia utile, ma ecco l' errore nel contesto e il repository in questione .)

Modifica 1: ecco alcuni altri interessanti output, dall'aggiunta di GIT_TRACE = 2:

Fetching submodule ppx-sedlex
23:55:28.125076 git.c:439               trace: built-in: git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix ppx-sedlex/
23:55:28.125914 run-command.c:663       trace: run_command: git-remote-https origin https://github.com/ELLIOTTCABLE/ppx-sedlex.git
23:55:28.429609 run-command.c:663       trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
23:55:28.432485 run-command.c:663       trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
23:55:28.434082 git.c:439               trace: built-in: git rev-list --objects --stdin --not --all --quiet --alternate-refs
From https://github.com/ELLIOTTCABLE/ppx-sedlex
 = [up to date]      develop       -> origin/develop
 = [up to date]      master        -> origin/master
 = [up to date]      v1.99.4       -> v1.99.4
 = [up to date]      v1.99.4-pre.1 -> v1.99.4-pre.1
 = [up to date]      v1.99.4-pre.3 -> v1.99.4-pre.3
 = [up to date]      v1.99.4-pre.8 -> v1.99.4-pre.8
 = [up to date]      v2.0.0        -> v2.0.0
 = [up to date]      v20.0.0-pre.1 -> v20.0.0-pre.1
 = [up to date]      v20.0.0-pre.2 -> v20.0.0-pre.2
23:55:28.442482 run-command.c:1616      run_processes_parallel: preparing to run up to 1 tasks
23:55:28.442504 run-command.c:1648      run_processes_parallel: done
23:55:28.442536 run-command.c:663       trace: run_command: git gc --auto
23:55:28.443983 git.c:439               trace: built-in: git gc --auto
23:55:28.444903 run-command.c:663       trace: run_command: cd /home/vagrant/ELLIOTTCABLE/bs-sedlex/.git/modules/ppx-sedlex; unset GIT_PREFIX; GIT_DIR=. git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix ppx-sedlex/ origin 0f509703fcd43ff4324d721a39220153bab49d4a
23:55:28.446392 git.c:439               trace: built-in: git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix ppx-sedlex/ origin 0f509703fcd43ff4324d721a39220153bab49d4a
23:55:28.447105 run-command.c:663       trace: run_command: git-remote-https origin https://github.com/ELLIOTTCABLE/ppx-sedlex.git
23:55:28.735871 run-command.c:663       trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --thin --no-progress https://github.com/ELLIOTTCABLE/ppx-sedlex.git/
23:55:28.738885 git.c:439               trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --thin --no-progress https://github.com/ELLIOTTCABLE/ppx-sedlex.git/
error: Server does not allow request for unadvertised object 0f509703fcd43ff4324d721a39220153bab49d4a

Non riesco a capire come mai Git sta richiedendo un "oggetto non pubblicizzato" qui; ma chiaramente non è un problema GitHub, qui - per qualche ragione, il comando:

git fetch --no-prune --no-prune-tags --tags -v \
   --recurse-submodules-default on-demand \ 
   --submodule-prefix ppx-sedlex/ \
   origin 0f509703fcd43ff4324d721a39220153bab49d4a

... viene automaticamente invocato sul sottomodulo, quando git fetchnel repository principale. (Ancora una volta, quel commit, 0f509703non esiste in nessuno dei repository; di nuovo, lo stesso identico repository, lo stesso identico commit, e questo non accade su macOS - solo sulle macchine Linux di Travis.)

git travis-ci git-submodules

— ELLIOTTCABLE
fonte

Ciò è particolarmente confuso, poiché né il repository principale bs-sedlex, né il git-submodule ppx-sedlex, hanno alcun commit a partire da 0f5097 ...;

Ma potrebbero avere un tag con quel SHA1 (che, una volta non referenziato, indicherebbe un commit)

Che cosa significa l'errore "fatale: remoto: upload-pack: non nostro riferimento";

Vedere "la clonazione di un repository con sottomoduli nidificati non funziona "

Git fornisce tre opzioni che controllano se è possibile recuperare un ID oggetto arbitrario:

uno che consente di recuperare qualsiasi oggetto arbitrario a cui Git ha accesso,

uno che consente di recuperare qualsiasi oggetto raggiungibile da un riferimento,

e uno che consente inoltre di recuperare oggetti raggiungibili da riferimenti nascosti.

Il messaggio "not our ref" indica che stai cercando di recuperare un oggetto tramite ID oggetto, che viene utilizzato per i sottomoduli, ma il server non lo consente.

Nel tuo caso, è possibile che:

o il tag nel sottomodulo non è mai stato inserito
oppure (poiché funziona da altre fonti) Travis-CI non ha accesso al sottomodulo ( dipendenze private ): vedere " Git - Sottomoduli in Travis CI ".
Oppure ha una versione cache di quel sottomodulo.

— VonC
fonte