Что означает «upload-pack: not our ref» при получении git-ссылок через --tags? - PullRequest
Новая
       39

Что означает «upload-pack: not our ref» при получении git-ссылок через --tags?

4 голосов
/ 09 октября 2019

В одном из моих проектов сборки Travis терпят неудачу, прежде чем какая-либо из моей системы сборки или кода может быть достигнута, как только мой скрипт сборки пытается извлечь все теги Git с помощью 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

Это особенно сбивает с толку, поскольку ни у основного репо bs-sedlex, ни у подмодуля git ppx-sedlex нет никаких коммитов, начинающихся как 0f5097...;Я понятия не имею, откуда этот SHA. Этот сбой происходит только на Linux рабочих, и я не могу понять, почему - git fetch --tags на том же репо работает на MacOS Travis-рабочих, на моей машине MacOS, и на Ubuntu Vagrantокно, которое я запускаю для отладки.

Что означает ошибка "fatal: remote error: upload-pack: not our ref";и как я могу обойти это? Я даже не уверен, с чего начать отладку этой ошибки, так как она возникает только у работников Travis.

(вряд ли это поможет, но вот ошибка в контексте и репозиторий, о котором идет речь .)

Редактировать 1: Вот еще один интересный вывод из добавления 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

Я могу 'не скрывать, почему Git запрашивает здесь «нерекламированный объект»;но это явно не проблема GitHub, здесь - по какой-то причине команда: 

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

... автоматически вызывается в субмодуле, когда я git fetch в родительском репо. (Опять же, этот коммит, 0f509703, не существует ни в одном репо; опять же, тот же репо, точно такой же коммит, и это не происходит в macOS - только на машинах Travis Linux.)

1 Ответ

0 голосов
/ 13 ноября 2019

Это особенно сбивает с толку, так как ни у основного репозитория bs-sedlex, ни у git-submodule ppx-sedlex нет коммитов, начинающихся с 0f5097 ...;

Но они могут иметь тег с этим SHA1 (который после разыменования будет указывать на коммит)

Что означает ошибка "fatal: remote error: upload-pack: not our ref";

См. " Клонирование репозитория с вложенными подмодулями не работает "

Git предоставляет три опции, которые определяют, можете ли вы получить произвольный идентификатор объекта:

  • , который позволяет выбрать любой произвольный объект, к которому Git имеет доступ,
  • один, который позволяет извлекать любой объект, достижимый из ссылки,
  • , и другой, который дополнительно позволяет извлекать объекты, достижимые из скрытых ссылок.

Сообщение «не наш ref» означает, что вы пытаетесь получить объект по идентификатору объекта, который используется для подмодулей, но сервер не разрешает это.

В вашем случае, возможно, что:

  • либо тег в подмодуле никогда не был выдвинут
  • , либо (так как он работает из других источников) Travis-CI не имеет доступа к подмодулю ( частные зависимости ): см. " Git - Подмодули в Travis CI ".
    Или у него есть некоторая кешированная версия этого подмодуля.
...