Отправка всех веток в GitLab не выполняется после нажатия одной ветки

Question

У меня есть несколько независимых веток в локальном репозитории, которые я хочу sh перенести в новое удаленное репо на 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

Answer 1

Это совсем недавно (август 2020 г.), за которым следует gitlab-org/gitlab проблема 233964

Сам ловушка запускается cmd/gitaly-hooks/hooks.go

Но, GitLab, использующий недавнюю Git 2.27 и строгание для Git 2.28, столкнулся с новым reference-transaction hook (который был введен в Git 2.27, июнь 2020 ):

Этот перехватчик вызывается любой командой Git, которая выполняет обновления ссылок. Он выполняется всякий раз, когда эталонная транзакция подготовлена, зафиксирована или прервана, и поэтому может вызываться несколько раз.

Поток добавляет:

Из-за проблем с производительностью reference-transaction hook использует кеш, поэтому ему не нужно повторно искать путь ловушки. Но если в рамках процесса выполняется еще одна ловушка, тогда кеш теперь указывает на эту вторую ловушку, а не на первую.

Попробуйте и посмотрите, поможет ли использование git push --no-verify -all в качестве временное решение.

Это приводит к gitlab-org/gitlab-git проблеме 1144 где Патрик Стейнхардт имеет отправил исправление вверх (что означает git/git список рассылки) .

Чтобы не искать повторно хук reference-transaction в случае, если он вызывается несколько раз, мы используем механизм кэширования, чтобы вызвать find_hook() только один раз . Однако было упущено то, что возвращаемое значение find_hook() на самом деле происходит от static strbuf, что означает, что оно будет перезаписано при повторном вызове find_hook(). В результате мы можем вызвать неправильный хук с параметрами хука reference-transaction.

Этот сценарий был обнаружен в дикой природе при выполнении git-push с несколькими ссылками, где есть чередующиеся вызовы как для update и привязка транзакции ссылки. Хотя первоначальные вызовы ловушки reference-transaction работают должным образом, она перестанет работать после следующего вызова ловушки update. В результате мы начинаем вызывать ловушку обновления с параметрами и стандартным вводом ловушки reference-transaction.

Эта фиксация устраняет проблему, сохраняя копию возвращаемого значения find_hook() в кеше.

OP Zorro Здесь добавляет в комментариях :

надеюсь, GitLab временно исправит это с их конца

Патрик также обращается к этой точке в MR 2454

В реализации ссылочной транзакции в git -core есть ошибка, которая вызывает чередование вызовов ловушка reference-transaction для случайного выполнения другой ловушки.

Хотя исправление было предложено в апстриме, самое раннее, что оно может быть доступно, - это Git v2.28.1. Итак, давайте пока удалим нашу ловушку ссылочной транзакции, чтобы не выявить это неправильное поведение.

Я отключаю эту ловушку в Gitaly, чтобы мы могли продолжить обновление до Git v2.28.0. Возврат всех различных MR к этой версии был бы большой проблемой.

Answer 2

попробуйте пропустить нажатую ветку, возможно, это приведет к конфликтам