Co oznacza „upload-pack: not our ref”, gdy pobierasz referencje git przez --tags?

10

W jednym z moich projektów kompilacje Travis kończą się niepowodzeniem, zanim będzie można uzyskać dostęp do dowolnego systemu kompilacji lub kodu, gdy tylko mój skrypt kompilacji spróbuje pobrać wszystkie tagi Git za pomocą 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

Jest to szczególnie mylące, ponieważ ani główne repozytorium bs-sedlex, ani podmoduł git nie ppx-sedlexmają żadnych początkowych zmian 0f5097...; Nie mam pojęcia, skąd pochodzi SHA. Ta awaria występuje tylko na pracownikach Linuxa i nie mogę zrozumieć, dlaczego - git fetch --tagsna tym samym repozytorium działa na macOS Travis-workers, na mojej maszynie macOS i na komputerze Ubuntu Vagrant, do którego debugowałem.

Co oznacza błąd „fatalny: błąd zdalny: upload-pack: not our ref”; i jak mogę to obejść? Nie jestem nawet pewien, od czego zacząć debugowanie tego błędu, ponieważ występuje on tylko w przypadku pracowników Travis.

(Jest mało prawdopodobne, aby był pomocny, ale oto błąd w kontekście i dane repozytorium ).

Edycja 1: Oto kilka dodatkowych interesujących wyników, dodając 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

Nie mogę się ukryć, dlaczego Git prosi o „niereklamowany obiekt” tutaj; ale najwyraźniej nie jest to problem GitHub, tutaj - z jakiegoś powodu polecenie:

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

... jest automatycznie wywoływane w submodule, gdy ja git fetchw repozytorium nadrzędnym. (Ponownie, to zatwierdzenie, 0f509703nie istnieje w żadnym repozytorium; ponownie, dokładnie to samo repo, dokładnie to samo zatwierdzenie, i to nie dzieje się na macOS - tylko na maszynach Linux Travisa).

git travis-ci git-submodules ELLIOTTCABLE
źródło

Odpowiedzi:

2

Jest to szczególnie mylące, ponieważ ani główny repozytorium bs-sedlex, ani podmoduł git ppx-sedlex, nie mają żadnych zatwierdzeń zaczynających się od 0f5097 ...;

Ale mogą mieć znacznik z tym SHA1 (który, po dereferencji, wskazywałby na zatwierdzenie)

Co oznacza błąd „fatalny: błąd zdalny: upload-pack: not our ref”;

Zobacz „ klonowanie repozytorium za pomocą zagnieżdżonych podmodułów nie działa ”

Git udostępnia trzy opcje, które kontrolują, czy możesz pobrać dowolny identyfikator obiektu:

  • taki, który pozwala pobrać dowolny dowolny obiekt, do którego Git ma dostęp,
  • taki, który pozwala pobrać dowolny obiekt dostępny z referencji,
  • oraz taki, który dodatkowo umożliwia pobieranie obiektów dostępnych z ukrytych odniesień.

Komunikat „not our ref” oznacza, że ​​próbujesz pobrać obiekt według identyfikatora obiektu, który jest używany w podmodułach, ale serwer na to nie pozwala.

W twoim przypadku może być możliwe, że:

  • albo znacznik w podmodule nigdy nie został wypchnięty
  • lub (ponieważ działa z innych źródeł) Travis-CI nie ma dostępu do submodułu ( zależności prywatne ): patrz „ Git - Submodules in Travis CI ”.
    Lub ma buforowaną wersję tego podmodułu.
VonC
źródło