With Git and submodules, you start with a minimum of two Git repositories. One is «your» repository—the main one, which Git will call the superproject. The second Git repository is some other Git repository: there is nothing special about it at all. It’s just that your superproject has in it these two parts:
-
Instructions for cloning the submodule. That lets your Git run
git cloneif needed, duringgit submodule update --initfor instance. -
The raw hash ID of some commit that should be in that other Git repository. Your main repository will, after cloning or running
git fetchif appropriate in your clone of the other Git repository, rungit checkout hashusing this raw hash ID.
Your superproject is asking for the hash ID 151d94a8754b0a612315fc191c5373cc0055c13d in the Git repository you can clone from https://github.com/scopatz/nanorc.git. That commit simply does not exist in that repository, so it’s not in any clone you make either.
Do you know why your superproject lists this commit hash ID, even though it does not exist? (I certainly don’t.) You cannot get it from their Git, because they don’t have it. That’s what all these error messages are telling you.
You can try searching other repositories (or Google) for 151d94a8754b0a612315fc191c5373cc0055c13d (I just tried with Google and they can’t find it). Or, if you don’t really care specifically for that commit, try telling your own Git—your superproject—that it should get some other commit, one that does exist and therefore you can get.
Which commit should you get? I have no idea: that’s up to you. Note that the place where your superproject lists the raw commit hash from the submodule is: in each commit. You can git checkout some commit, probably the tip of some branch, in your superproject. Then you can enter the submodule, pick a commit you like, use git checkout in that submodule—it’s another Git clone, after all, so you can do any Git command there—to check out the desired commit. Then, exit the submodule (change directories back to your superproject) and run git add on the submodule path and git commit to record the new desired hash ID. This new commit now asks for that particular hash ID.
We are seeing an odd error only on our CI. We have a git repository (let’s call it «OUTER») which contains one submodule («INNER»). If we clone «OUTER» normally on our development machines and update submodules, we see no issues. On CI, after the odd way Bitrise «clones» the repo, calling git fetch throws an error when attempting to fetch the submodule.
Here is an example output. Notice the first few lines simulate how Bitrise «clones» the repo.
➜ test git "init"
git "remote" "add" "origin" "git@github.com:COMPANY/OUTER.git"
git "fetch" "--jobs=10" "--no-tags" "origin" "refs/heads/master"
git "checkout" "master"
git "merge" "origin/master"
git "submodule" "update" "--init" "--recursive" "--jobs=10"
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /Users/lnatan/Desktop/test/.git/
remote: Enumerating objects: 48542, done.
remote: Counting objects: 100% (4094/4094), done.
remote: Compressing objects: 100% (989/989), done.
remote: Total 48542 (delta 3383), reused 3623 (delta 3082), pack-reused 44448
Receiving objects: 100% (48542/48542), 178.80 MiB | 5.71 MiB/s, done.
Resolving deltas: 100% (35468/35468), done.
From github.com:COMPANY/OUTER
* branch master -> FETCH_HEAD
* [new branch] master -> origin/master
Branch 'master' set up to track remote branch 'master' from 'origin'.
Already on 'master'
Already up to date.
Submodule 'Submodules/INNER' (git@github.com:COMPANY/INNER.git) registered for path 'Submodules/INNER'
Cloning into '/Users/lnatan/Desktop/test/Submodules/INNER'...
Submodule path 'Submodules/INNER': checked out '174a9f60014e3cead89242178c534aeaff769dc7'
➜ test git:(master)
➜ test git:(master)
➜ test git:(master)
➜ test git:(master) git fetch
remote: Enumerating objects: 9001, done.
remote: Counting objects: 100% (4953/4953), done.
remote: Compressing objects: 100% (2833/2833), done.
remote: Total 4461 (delta 3443), reused 2361 (delta 1527), pack-reused 0
Receiving objects: 100% (4461/4461), 6.16 MiB | 3.41 MiB/s, done.
Resolving deltas: 100% (3443/3443), completed with 399 local objects.
From github.com:COMPANY/OUTER
= [up to date] master -> origin/master
* [new branch] ...
* [new tag] ...
Fetching submodule Submodules/INNER
fatal: remote error: upload-pack: not our ref 57df880c914a482c26a1db9b388a34ee55e22730
Errors during submodule fetch:
Submodules/INNER
Using GIT_TRACE=2 and --verbose produces the following output:
➜ test git:(master) GIT_TRACE=2 git fetch --tags --verbose
02:04:41.644506 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/bin/git
02:04:41.644795 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/bin
02:04:41.645153 git.c:455 trace: built-in: git fetch --tags --verbose
02:04:41.645516 run-command.c:667 trace: run_command: unset GIT_PREFIX; GIT_PROTOCOL=version=2 ssh -o SendEnv=GIT_PROTOCOL git@github.com 'git-upload-pack '''COMPANY/OUTER.git''''
remote: Enumerating objects: 9300, done.
remote: Counting objects: 100% (5243/5243), done.
remote: Compressing objects: 100% (3091/3091), done.
02:04:48.411851 run-command.c:667 trace: run_command: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 30246 on Leo-Natans-Inv-MBP.local' --pack_header=2,4750
02:04:48.417901 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
02:04:48.418587 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
02:04:48.419008 git.c:455 trace: built-in: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 30246 on Leo-Natans-Inv-MBP.local' --pack_header=2,4750
remote: Total 4750 (delta 3673), reused 2442 (delta 1552), pack-reused 0
Receiving objects: 100% (4750/4750), 6.22 MiB | 3.51 MiB/s, done.
Resolving deltas: 100% (3673/3673), completed with 400 local objects.
02:04:50.742376 run-command.c:667 trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
02:04:50.747795 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
02:04:50.748441 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
02:04:50.748944 git.c:455 trace: built-in: git rev-list --objects --stdin --not --all --quiet --alternate-refs
From github.com:COMPANY/OUTER
= [up to date] master -> origin/master
* [new branch] ...
* [new tag] ...
02:04:51.133204 run-command.c:1628 run_processes_parallel: preparing to run up to 1 tasks
02:04:51.133359 run-command.c:667 trace: run_command: cd /Users/lnatan/Desktop/test/.git/modules/Submodules/INNER; unset GIT_PREFIX; GIT_DIR=. git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix Submodules/INNER/
Fetching submodule Submodules/INNER
02:04:51.135930 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
02:04:51.136231 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
02:04:51.136416 git.c:455 trace: built-in: git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix Submodules/INNER/
02:04:51.136872 run-command.c:667 trace: run_command: unset GIT_DIR GIT_PREFIX; GIT_PROTOCOL=version=2 ssh -o SendEnv=GIT_PROTOCOL git@github.com 'git-upload-pack '''COMPANY/INNER.git''''
02:04:55.589678 run-command.c:667 trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
02:04:55.600024 run-command.c:667 trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
02:04:55.603178 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
02:04:55.603586 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
02:04:55.603916 git.c:455 trace: built-in: git rev-list --objects --stdin --not --all --quiet --alternate-refs
From github.com:COMPANY/INNER
= [up to date] ...
02:04:55.938232 run-command.c:1628 run_processes_parallel: preparing to run up to 1 tasks
02:04:55.938375 run-command.c:1660 run_processes_parallel: done
02:04:55.938496 run-command.c:667 trace: run_command: git maintenance run --auto --no-quiet
02:04:55.946682 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
02:04:55.947423 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
02:04:55.948094 git.c:455 trace: built-in: git maintenance run --auto --no-quiet
02:04:55.951412 run-command.c:667 trace: run_command: cd /Users/lnatan/Desktop/test/.git/modules/Submodules/INNER; unset GIT_PREFIX; GIT_DIR=. git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix Submodules/INNER/ origin 57df880c914a482c26a1db9b388a34ee55e22730
02:04:55.956634 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
02:04:55.957121 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
02:04:55.957479 git.c:455 trace: built-in: git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix Submodules/INNER/ origin 57df880c914a482c26a1db9b388a34ee55e22730
02:04:55.958394 run-command.c:667 trace: run_command: unset GIT_DIR GIT_PREFIX; GIT_PROTOCOL=version=2 ssh -o SendEnv=GIT_PROTOCOL git@github.com 'git-upload-pack '''COMPANY/INNER.git''''
fatal: remote error: upload-pack: not our ref 57df880c914a482c26a1db9b388a34ee55e22730
02:05:00.643367 run-command.c:1660 run_processes_parallel: done
Errors during submodule fetch:
Submodules/INNER
02:05:00.644990 run-command.c:667 trace: run_command: git maintenance run --auto --no-quiet
02:05:00.652674 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
02:05:00.653655 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
02:05:00.654379 git.c:455 trace: built-in: git maintenance run --auto --no-quiet
I can’t figure out where 57df880c914a482c26a1db9b388a34ee55e22730 comes from. I cannot find any reference to it anywhere, but I might not know where to look. Any assistance?
Thanks
Open
Issue created May 31, 2019 by
git clone fails with «not our ref» to active-active gitlab-ee cluster
fatal: remote error: upload-pack: not our ref ffff000011112222333344445555666677778888
fatal: the remote end hung up unexpectedlySummary
gitlab-ee active-active cluster receives a git push to an NFS backed git-data store. gitlab-runner picks up a build job for a very recently pushed commit (speculation) and upon trying to fetch it over http, gets requests split over the gitlab application server cluster at which point part of the cluster serves bad data to the runner and causes the job to fail.
Steps to reproduce
This happens on gitlab-runner using the docker executor, after the container is fetched, when the code repository is cloned. Happens with «Reinitialized existing Git repository» as well, happens intermittently, suspect happens when git clone is routed to multiple application servers with nfs backed git-data.
.gitlab-ci.yml
test runner:
image: debian:stretch
script:
- echo hello worldActual behavior
Upon encountering a git clone error «remote error: upload-pack: not our ref» the job fails and gives up, and requires human intervention to retry the job at which point it works (reliably AFAICT).
Expected behavior
Gitlab-runner makes a good faith effort to retry synchronization-based failures that occur outside of the tasks controlled by the repository .gitlab-ci-yml file. Or otherwise, automatically retrying a build job that fails over an internal error that is likely due to synchronization issues.
There are comments that this error is http specific due to the way the http git fetch machinery does multiple requests, where as the ssh clone uses a single connection. Possibly the expected behaviour is that a connection protocol who’s reliability isn’t tied to the topology of the gitlab application is used (like ssh or a modified http transport that uses a single connection?). I’m open to the gitlab-runner team’s export input on how this should work.
Relevant logs and/or screenshots
job log
Running with gitlab-runner 11.10.1 (1f513601)
on gitlab-runner-worker REDACTED
Using Docker executor with image mydockerregistry.example.org/name/namespace:latest ...
Pulling docker image mydockerregistry.example.org/name/namespace:latest ...
Using docker image sha256:0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff for mydockerregistry.example.org/name/namespace:latest ...
Running on runner-REDACTED-project-9999-concurrent-0 via runner-REDACTED-gitlab-runner-worker-1111222233-aabbccdd...
Reinitialized existing Git repository in /builds/mygitrepo/mygitrepo/.git/
Fetching changes...
fatal: remote error: upload-pack: not our ref aaaabbbbccccddddeeeeffff0000111122223333
fatal: the remote end hung up unexpectedly
ERROR: Job failed: exit code 1
Environment description
custom installation (runner bastion with an ephemeral single-use gitlab runner behind it)
docker executor
docker is provided by a managed provider who does not expose version information or runner configuration.
config.toml contents
Used GitLab Runner version
Running with gitlab-runner 11.10.1 (1f513601)
on gitlab-runner-worker REDACTED
Using Docker executor with image REDACTED—>
Possible fixes
Comments from forums suggest there isn’t a simple fix in the git protocol, I suspect gitlab might be able to assert an application node has the tip update, or otherwise introduce a delay and try to flush the git ref cache to try to serve a request that should be good, idk.
https://github.com/git/git/blob/aa25c82427ae70aebf3b8f970f2afd54e9a2a8c6/upload-pack.c#L615
У меня есть репозиторий git с несколькими подмодулями. Я попытался удалить и добавить соответствующий подмодуль (nanorc от scopatz), однако ошибка сохраняется в удаление и повторное добавление. Когда я клонирую репо в новое место, я автоматически обновляю его с помощью git submodule update --init --recursive, когда это не удается, но только для этого подмодуля … Ниже приведены соответствующие выходные данные команды с GIT_TRACE=2:
23:01:26.918691 run-command.c:1569 run_processes_parallel: preparing to run up to 1 tasks
23:01:26.933567 run-command.c:1601 run_processes_parallel: done
23:01:26.934373 run-command.c:646 trace: run_command: git gc --auto
23:01:26.966805 git.c:344 trace: built-in: git gc --auto
23:01:26.991059 git.c:344 trace: built-in: git rev-parse --local-env-vars
23:01:27.015684 git.c:344 trace: built-in: git rev-parse --local-env-vars
23:01:27.032282 git.c:344 trace: built-in: git symbolic-ref -q HEAD
23:01:27.053948 git.c:344 trace: built-in: git config --get branch.master.remote
23:01:27.073636 git.c:344 trace: built-in: git fetch origin 151d94a8754b0a612315fc191c5373cc0055c13d
23:01:27.079657 run-command.c:646 trace: run_command: git-remote-https origin https://github.com/scopatz/nanorc.git
23:01:28.441725 run-command.c:646 trace: run_command: git rev-list --objects --stdin --not --all --quiet
23:01:28.452267 run-command.c:646 trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
23:01:28.467757 git.c:344 trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
fatal: remote error: upload-pack: not our ref 151d94a8754b0a612315fc191c5373cc0055c13d
fatal: The remote end hung up unexpectedly
Fetched in submodule path 'submodules/nano', but it did not contain 151d94a8754b0a612315fc191c5373cc0055c13d. Direct fetching of that commit failed.
Надеюсь, что кто-то здесь может помочь, я в основном потерялся на этом этапе.
=== РЕДАКТИРОВАТЬ: шаги решения ниже ===
cd {submodule path}
git reset --hard origin/master
cd -
git clean -n
git add {submodule path}
git commit
git submodule update --init --recursive
Ошибок нет, круто.
5 ответов
Лучший ответ
Используя Git и подмодули, вы начинаете как минимум с двух репозиториев Git. Один из них — это «ваш» репозиторий — основной, который Git будет называть суперпроектом . Второй репозиторий Git — это какой-то другой репозиторий Git: в нем вообще нет ничего особенного. Просто в вашем суперпроекте есть эти две части:
-
Инструкция по клонированию подмодуля. Это позволяет вашему Git запускать
git cloneпри необходимости, например, во времяgit submodule update --init. -
Необработанный хэш-идентификатор некоторого коммита, который должен быть в другом репозитории Git. Ваш основной репозиторий после клонирования или запуска
git fetch, если это необходимо, в вашем клоне другого репозитория Git, запуститgit checkout hashс использованием этого необработанного хеш-идентификатора.
Ваш суперпроект запрашивает хэш-идентификатор 151d94a8754b0a612315fc191c5373cc0055c13d в репозитории Git, который вы можете клонировать из https: // github.com/scopatz/nanorc.git. Этого коммита просто не существует в этом репозитории, поэтому его также нет ни в одном созданном вами клоне.
Знаете ли вы, почему ваш суперпроект перечисляет этот хэш-идентификатор коммита, хотя его не существует? (Я, конечно, не знаю.) Вы не можете получить это из их Git, потому что у них этого нет. Вот что вам говорят все эти сообщения об ошибках.
Вы можете попробовать поискать 151d94a8754b0a612315fc191c5373cc0055c13d в других репозиториях (или в Google) (я только что пробовал использовать Google, но они не могут его найти). Или, если вас действительно не интересует этот коммит, попробуйте сообщить своему собственному Git — вашему суперпроекту — что он должен получить какой-нибудь другой коммит, тот, который существует, и поэтому вы можете получить.
Какую фиксацию следует получить? Понятия не имею: решать вам. Обратите внимание, что место где в вашем суперпроекте перечисляет необработанный хэш фиксации из подмодуля: в каждой фиксации. Вы можете git checkout коммит, возможно, вершину какой-то ветки в вашем суперпроекте. Затем вы можете войти в подмодуль, выбрать понравившуюся фиксацию, использовать git checkout в этом подмодуле — в конце концов, это еще один клон Git, так что вы можете выполнить там любую команду Git — чтобы проверить желаемую фиксацию. Затем выйдите из подмодуля (смените каталоги обратно на свой суперпроект) и запустите git add на пути подмодуля и git commit, чтобы записать новый желаемый идентификатор хэша. Эта новая фиксация теперь запрашивает этот конкретный идентификатор хэша.
7
torek
11 Апр 2020 в 23:32
Я столкнулся с этой проблемой, когда пытался обновить подмодули в ветке, которую я создал перед ветвлением некоторых из подмодулей. Итак, у меня был repo1 branch-x, в котором есть несколько подмодулей, и только после этого branch-x был создан для некоторых из подмодулей. Мое решение заключалось в том, чтобы зациклить подмодули и сбросить ветки:
cd the-main-repo-dir
foreach submodlue in submodules do {
cd {submodule path}
git reset --hard origin/brnach-x
cd -
}
git submodule update --init --recursive
git push origin/branch-x
1
hagits
7 Фев 2021 в 20:12
Я получил эту ошибку при клонировании одного из репозиториев с подмодулем, в то время как исходное локальное репо работало нормально. Проблема заключалась в том, что я забыл нажать на изменения подмодуля.
Итак, не забудьте зафиксировать и отправить все изменения вашего подмодуля.
2
Jahmic
21 Мар 2021 в 11:21
У меня была такая же ошибка с нашими субмодулями. Поскольку проект общедоступен, чтобы исправить это, я заменяю все значения в URL-адресах в .git / config и в их индивидуальной конфигурации подмодуля проектами https вместо ssh
0
ALBlancoIV
4 Авг 2021 в 10:32
Если вы сделали коммиты в подмодуле
… тогда общая проблема в том, что вы
- … добавил этот коммит в суперпроект,
- толкнул суперпроект,
- но не подтолкнул подмодуль.
Итак, в вашем локальном рабочем пространстве все в порядке, но суперпроект относится к фиксации подмодуля, который (пока) не существует на удаленной машине. Это то, что приводит к сообщению.
Решение
git push --recurse-submodules=on-demand
0
Lutz Prechelt
31 Авг 2021 в 10:58
В одном из моих проектов сборки 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-works, на моей машине с macOS и на Ubuntu Vagrant box, который я запускаю для отладки.
Что означает ошибка «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).