Was bedeutet „upload-pack: not our ref“ beim Abrufen von Git-Refs über –tags?

In einem meiner Projekte schlagen die Travis-Builds fehl, bevor mein Build-System oder Code erreicht werden kann, sobald mein Build-Skript versucht, alle Git-Tags mit abzurufen 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

Dies ist besonders verwirrend, da weder das Haupt-Repo bs-sedlexnoch das git-submodul ppx-sedlexhaben Sie einen Commit, der wie folgt beginnt 0f5097...; Ich habe keine Ahnung, woher dieser SHA kommt. Dieser Fehler tritt nur auf auf Linux Arbeiter, und ich kann nicht herausfinden, warum – git fetch --tags auf demselben Repo funktioniert auf den macOS Travis-Workern, auf meinem macOS-Rechner und auf einer Ubuntu Vagrant-Box, die ich hochgefahren habe, um dies zu debuggen.

Was bedeutet der Fehler „fatal: remote error: upload-pack: not our ref“? und wie kann ich das umgehen? Ich bin mir nicht einmal sicher, wo ich mit dem Debuggen dieses Fehlers beginnen soll, da er nur speziell bei Travis-Workern auftritt.

(Es ist unwahrscheinlich, dass es hilfreich ist, aber hier ist das Fehler im Kontextund das betreffende Depot.)

Bearbeiten 1: Hier ist eine zusätzliche interessante Ausgabe nach dem Hinzufügen von 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

Ich kann mir nicht erklären, warum Git hier ein „unbeworbenes Objekt“ anfordert; aber es ist eindeutig kein GitHub-Problem, hier – aus irgendeinem Grund der Befehl:

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

… wird automatisch auf dem Submodul aufgerufen, wenn I git fetch im übergeordneten Repo. (Auch diese Verpflichtung, 0f509703, existiert in keinem Repo; wieder das exakt gleiche Repo, das exakt gleiche Commit, und das passiert nicht auf macOS – nur auf den Linux-Rechnern von Travis.)

Dies ist besonders verwirrend, da weder das Hauptrepo bs-sedlex noch das Git-Submodul ppx-sedlex einen Commit haben, der wie 0f5097 beginnt…;

Aber sie könnten eine haben Schild mit diesem SHA1 (das nach der Dereferenzierung auf ein Commit zeigen würde)

Was bedeutet der Fehler „fatal: remote error: upload-pack: not our ref“?

Siehe “Klonen eines Repos mit verschachtelten Submodulen funktioniert nicht”

Git bietet drei Optionen, die steuern, ob Sie eine beliebige Objekt-ID abrufen können:

• eine, die es erlaubt, jedes beliebige Objekt zu holen, auf das Git Zugriff hat,
• eine, die es erlaubt, jedes Objekt zu holen, das von einer Referenz aus erreichbar ist,
• und eine, die zusätzlich das Abrufen von Objekten erlaubt, die von versteckten Referenzen erreichbar sind.

Die Meldung „nicht unsere Referenz“ bedeutet, dass Sie versuchen, ein Objekt anhand der Objekt-ID abzurufen, die für Submodule verwendet wird, der Server dies jedoch nicht zulässt.

In Ihrem Fall könnte Folgendes möglich sein:

• Entweder wurde das Tag im Submodul nie gepusht
• oder (da es von anderen Quellen aus funktioniert) hat Travis-CI keinen Zugriff auf das Submodul (private Abhängigkeiten): sehen “Git – Untermodule in Travis CI “.
  Oder es hat eine zwischengespeicherte Version dieses Submoduls.

Ich hatte den gleichen Fehler:

radato$ git submodule update 
fatal: git upload-pack: not our ref somehash0
fatal: remote error: upload-pack: not our ref somehash0
fatal: Fetched in submodule path 'dashboard', but it did not contain somehash0. Direct fetching of that commit failed.

Also habe ich das Submodul deinitialisiert:

radato$ git submodule deinit -f dashboard
Cleared directory 'dashboard'
Submodule 'dashboard' (ssh://[email protected]/somedomain/dashboard.git) unregistered for path 'dashboard'

Überprüfen Sie jetzt die Zusammenfassung, die ich bekomme

radato@$ git submodule summary 
* somepath1 somehash1 (2):
  < Merged in fixed_edge (pull request #2)
  < fixed broken test

* somepath2 somehash2 (2):
  < Merged in dsp_tx_freq (pull request #14)
  < Merged in v0.2.0 (pull request #13)

Irgendwann habe ich gezogen:

radato@$ git pull --prune --recurse-submodules --force 
Fetching submodule dashboard
Fetching submodule somepath1
Fetching submodule somepath2
Already up to date.
Submodule path 'somesubmodulepath1': checked out 'somehash1'
Submodule path 'somesubmodulepath2': checked out 'somehash2'

Und jetzt funktioniert es wieder. Hier ist der Status

radato$ git status 
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

In meinem Fall habe ich das Problem dadurch gelöst git reset --hard <for sure more than 100 commits before ref>.

Dann tat ich es einfach git pull und es hat funktioniert. Da es mit dem Verfahren sofort funktionierte, habe ich kein anderes ausprobiert, daher kann ich keinen deterministischen Ansatz zur Behebung dieses Problems bereitstellen.