gitlab - 推送单个分支后，推送 GitLab 上的所有分支失败

Question

我在本地存储库中有多个独立分支，我想将它们推送到 gitlab 上的新远程存储库。但是当我使用 git push -u origin -all 时，上传单个分支后操作一直失败。我刚刚在 gitlab 上创建了新的存储库，没有更改任何内容或添加任何 Hook 。我可以做任何事情来确保我的所有分支都被推送到远程存储库，因为我经常会推送多个分支。 (分支是独立的，因为这些更改来自不使用 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

Answer 1

这是最近的事(2020 年 8 月)，随后是 gitlab-org/gitlab issue 233964

钩子(Hook)本身由 cmd/gitaly-hooks/hooks.go 触发

但是，GitLab 使用最近的 Git 2.27 并计划 Git 2.28，它面临着 the new reference-transaction hook (这是 introduced in Git 2.27, June 2020 ):

This hook is invoked by any Git command that performs reference updates.
It executes whenever a reference transaction is prepared, committed or aborted and may thus get called multiple times.

线程添加:

Due to performance concerns, the reference-transaction hook is using a cache so it doesn't have to repeatedly find the hook path again.
But in case another hook is getting executed as part of the process, then the cache now points to that second hook instead of the first.

试试看是否使用git push --no-verify -all会有所帮助，作为临时解决方法。

这导致 gitlab-org/gitlab-git issue 1144其中 Patrick Steinhardt有sent a fix upstream (meaning to git/git mailing list) .

In order to not repeatedly search for the reference-transaction hook in case it's getting called multiple times, we use a caching mechanism to only call find_hook() once.
What was missed though is that the return value of find_hook() actually comes from a static strbuf, which means it will get overwritten when calling find_hook() again.
As a result, we may call the wrong hook with parameters of the reference-transaction hook.

This scenario was spotted in the wild when executing a git-push with multiple references, where there are interleaving calls to both the update and the reference-transaction hook.
While initial calls to the reference-transaction hook work as expected, it will stop working after the next invocation of the update hook.
The result is that we now start calling the update hook with parameters and stdin of the reference-transaction hook.

This commit fixes the issue by storing a copy of find_hook()'s returnvalue in the cache.

OP Zorro Here添加 in the comments :

hopefully GitLab will temporarily fix it from their end

Patrick 还在 MR 2454 中解决了这一点

There's a bug in the reference-transaction implementation in git-corewhich will cause interleaving calls to the reference-transaction hook toexecute another hook by accident.

While a fix has been proposed upstream, the earliest it may be available is with Git v2.28.1.
So let's remove our reference-transaction hook for now to not expose this brokenbehaviour.

I'm disabling this hook in Gitaly so that we can move ahead with the upgrade to Git v2.28.0.
Reverting all the different MRs towards that version would be a major pain.

---

请注意，关于引用事务 Hook ，Git 2.32(2021 年第二季度)更加明确:

参见 commit 23c781f , commit 5f308a8 (2021 年 3 月 1 日)Patrick Steinhardt ( pks-t ) .
^{(由 Junio C Hamano -- gitster -- 合并于 commit 20adca9，2021 年 3 月 22 日)}

githooks.txt: clarify documentation on reference-transaction hook

^{Signed-off-by: Patrick Steinhardt}

The reference-transaction hook doesn't clearly document its scope and what values it receives as input.
Document it to make it less surprising and clearly delimit its (current) scope.

githooks现在包含在其 man page 中:

The hookdoes not cover symbolic references (but that may change in the future).

githooks现在包含在其 man page 中:

For each reference update that was added to the transaction, the hookreceives on standard input a line of the format:

<old-value> SP <new-value> SP <ref-name> LF

where:

• <old-value> is the old object name passed into the referencetransaction,
• <new-value> is the new object name to be stored in theref and
• <ref-name> is the full name of the ref.

When force updating the reference regardless of its current value or when the reference is to be created anew, <old-value> is the all-zeroes object name.
To distinguish these cases, you can inspect the current value of<ref-name> via git rev-parse.