我在本地存储库中有多个独立的分支,我想将其推送到gitlab上的新远程仓库中。但是,当我使用git push -u origin -all
时,上载单个分支后操作仍然失败。我刚刚在gitlab上创建了新的存储库,而没有进行任何更改或添加任何挂钩。为了确保将所有分支都推送到远程存储库,我可以做任何事情,因为我经常会推送多个分支。 (分支是独立的,因为这些更改来自不使用git的团队成员)
我在github上尝试了完全相同的方法,所有分支均被推送,没有任何问题。
以下是我为gitlab运行此命令时得到的输出,
$ git push -u origin --all
Counting objects: 582, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (582/582), done.
Writing objects: 100% (582/582), 210.92 KiB | 2.42 MiB/s, done.
Total 582 (delta 456), reused 0 (delta 0)
remote: Resolving deltas: 100% (456/456), completed with 71 local objects.
error executing git hookerror executing git hookfatal: ref updates aborted by hook
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
答案 0 :(得分:1)
这是最近的情况(2020年8月),随后是gitlab-org/gitlab
issue 233964
挂钩本身是由cmd/gitaly-hooks/hooks.go
但是,GitLab使用最新的Git 2.27并规划了Git 2.28,它面临着the new reference-transaction
hook(原为introduced in Git 2.27, June 2020):
任何执行引用更新的Git命令都会调用此钩子。
每当准备,提交或中止引用事务时,它就会执行,因此可能会多次调用。
线程添加:
由于性能方面的考虑,
reference-transaction
钩子正在使用缓存,因此不必再次重复查找钩子路径。
但是,如果另一个钩子正在作为该过程的一部分执行,那么缓存现在将指向该第二个钩子,而不是第一个。
尝试并尝试使用git push --no-verify -all
是否有帮助,作为一种临时解决方法。
这导致gitlab-org/gitlab-git
issue 1144,其中Patrick Steinhardt有sent a fix upstream (meaning to git/git
mailing list)。
为了避免在多次调用
reference-transaction
时重复搜索find_hook()
钩子,我们使用缓存机制仅调用一次find_hook()
。
不过,遗漏的是static strbuf
的返回值实际上来自find_hook()
,这意味着当再次调用reference-transaction
时它将被覆盖。
结果,我们可能使用git-push
钩子的参数调用了错误的钩子。在执行带有多个引用的
reference-transaction
时,发现这种情况很普遍,其中对update和reference-transaction钩子都有交错调用。
最初对update
挂钩的调用按预期工作时,它将在下一次调用reference-transaction
挂钩后停止工作。
结果是我们现在开始使用find_hook()
钩子的参数和stdin调用更新钩子。此提交通过存储
reference-transaction
返回的副本来解决此问题 缓存中的值。
OP Zorro Here添加in the comments:
希望GitLab会从头开始临时修复它
帕特里克(Patrick)也解决了MR 2454中的这一点
git-core的引用交易实现中存在错误 这将导致对{{1}}钩子的交错调用 意外执行另一个钩子。
虽然已在上游提出了修复程序,但最早可用的是Git v2.28.1。
因此,让我们现在删除我们的引用交易挂钩,以免暴露此损坏的 行为。我正在Gitaly中禁用此挂钩,以便我们可以继续升级到Git v2.28.0。
将所有不同的MR恢复为该版本将是一个很大的麻烦。
答案 1 :(得分:0)
尝试跳过推送的分支,可能会产生冲突