在我的一个项目中,一旦我的构建脚本尝试使用git fetch --tags
来获取所有Git标签,Travis的构建就会失败,而我的任何构建系统或代码都无法访问。
worker上发生,我不知道为什么-在同一个仓库中的`` 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-submoduleppx-sedlex
都没有像0f5097...
那样的提交;我不知道SHA的来源。此失败仅在Linux
git fetch --tags
在macOS Travis-workers,我的macOS机器和Ubuntu Vagrant盒上都可以工作进行调试以调试它。“致命错误:远程错误:upload-pack:不是我们的引用”表示什么;我该如何解决?我什至不知道从哪里开始调试此错误,因为它仅发生在Travis worker上。
(不太可能有帮助,但这是error in context和the repository in question。)
编辑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
当父存储库中的Igit fetch
时,会自动在子模块上调用...。 (同样,该提交
0f509703
在任何一个仓库中都不存在;同样,完全相同的仓库,完全相同的提交,并且在macOS上没有发生–仅在Travis的Linux机器上。)
在我的一个项目中,一旦我的构建脚本尝试使用git fetch --tags来获取所有Git标签,Travis的构建就会失败,而我的任何构建系统或代码都无法访问。 ...
这特别令人困惑,因为主仓库bs-sedlex或git-submodule ppx-sedlex都没有像0f5097那样的提交。