Was bedeutet "Upload-Pack: nicht unser Ref", wenn Git-Refs über --tags abgerufen werden?

In einem meiner Projekte schlagen die Travis-Builds fehl, bevor eines meiner Build-Systeme oder mein Code erreicht werden kann, sobald mein Build-Skript versucht, alle Git-Tags abzurufen mit 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-sedlexein Commit haben, das wie folgt beginnt 0f5097.... Ich habe keine Ahnung, woher dieser SHA kommt. Dieser Fehler tritt nur bei den Linux- Workern auf, und ich kann nicht herausfinden, warum - git fetch --tagsauf demselben Repo funktioniert es auf den macOS Travis-Workern, auf meinem macOS-Computer und auf einer Ubuntu Vagrant-Box, die ich zum Debuggen hochgefahren habe.

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 bei Travis-Mitarbeitern auftritt.

(Es ist unwahrscheinlich, dass es hilfreich ist, aber hier ist der Fehler im Kontext und das betreffende Repository .)

Bearbeiten 1: Hier sind einige zusätzliche interessante Ausgaben aus 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 vorstellen, warum Git hier ein "unangekündigtes Objekt" anfordert. Aber hier ist es eindeutig kein GitHub-Problem - 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 ich git fetchim übergeordneten Repo bin . (Auch dieses Commit 0f509703existiert in keinem Repo; wieder genau dasselbe Repo, genau dasselbe Commit, und dies geschieht nicht unter macOS - nur auf Travis 'Linux-Rechnern.)

Dies ist besonders verwirrend, da weder das Haupt-Repo-bs-Sedlex noch das Git-Submodul ppx-sedlex ein Commit haben, das wie 0f5097 beginnt ...;

Möglicherweise haben sie jedoch ein Tag mit diesem SHA1 (das nach der Dereferenzierung auf ein Commit verweist).

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

Siehe "Das 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 das Abrufen eines beliebigen Objekts ermöglicht, auf das Git Zugriff hat,
• eine, die das Abrufen eines beliebigen Objekts ermöglicht, das von einer Referenz aus erreichbar ist,
• und eine, die zusätzlich das Abrufen von Objekten ermöglicht, die aus versteckten Referenzen erreichbar sind.

Die Meldung "Nicht unser Verweis" 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 ist möglicherweise Folgendes möglich:

• Entweder wurde das Tag im Submodul nie verschoben
• oder (da es aus anderen Quellen funktioniert) Travis-CI hat keinen Zugriff auf das Submodul ( private Abhängigkeiten ): siehe " Git - Submodule in Travis CI ".
  Oder es hat eine zwischengespeicherte Version dieses Submoduls.