фатальный: ранний EOF фатальный: сбой индексного пакета

У меня точно такая же проблема. Следуя первому шагу выше, я смог клонировать, но больше ничего сделать не могу. Не удается получить, вытащить или проверить старые ветки.

Каждая команда работает намного медленнее, чем обычно, а затем умирает после сжатия объектов.

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

Это также происходит, когда ваши ссылки используют слишком много памяти. Обрезка памяти исправила это для меня. Просто добавьте ограничение на то, что вы получаете так ->

git fetch --depth=100

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

Используя ответ @cmpickle, я создал скрипт, упрощающий процесс клонирования.

Он размещен здесь: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67340fb7c03c03c03.

curl -sL https://git.io/JvtZ5 | sh -s repo_uri repo_folder

Касательно связано и полезно только в том случае, если у вас нет корневого доступа и вы вручную извлекаете Git из RPM (с rpm2cpio) или другого пакета (.deb, ..) в подпапку. Типичный пример использования: вы пытаетесь использовать более новую версию Git вместо устаревшей на корпоративном сервере.

Если git clone завершается ошибкой с fatal: index-pack failed без предварительного упоминания EOF, но вместо этого появляется справочное сообщение о usage: git index-pack, это значит, что существует несоответствие версии, и вам нужно запустить git с параметром --exec-path:

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

Чтобы это происходило автоматически, укажите в своем ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

У меня была такая же проблема, я даже пытался скачать проект прямо с сайта в виде zip-файла, но загрузка прерывалась на тех же процентах.

Эта единственная строка исправила мою проблему как шарм

git config --global core.compression 0

Я знаю, что об этом упоминалось в других ответах, но никто здесь не упомянул, что эта строка одна может решить проблему.

Надеюсь, поможет.

Это сбивает с толку, потому что журналы Git могут указывать на любые ошибки подключения или авторизации ssh, например: ssh_dispatch_run_fatal: Connection to x.x.x.x port yy: message authentication code incorrect, the remote end hung up unexpectedly, early EOF.

Решение на стороне сервера

Оптимизируем репозиторий git на стороне сервера:

1. Войдите в репозиторий git bare моего сервера.
2. Вызовите git gc.
3. Вызов git repack -A

Eg:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc
git repack -A

Теперь я могу клонировать этот репозиторий без ошибок, например. на стороне клиента:

git clone git@my_server_url.com:my_repo_name

Команду git gc можно вызвать на стороне клиента git, чтобы избежать подобной проблемы git push.

Если вы являетесь администратором службы Gitlab, активируйте Housekeeping вручную. Он вызывает внутренние git gc или git repack.

Решение на стороне клиента

Другое (хак, только на стороне клиента) решение загружает последний мастер без истории:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

Есть шанс, что переполнения буфера не произойдет.

В моем случае проблема заключалась не в параметрах конфигурации git, а в том, что в моем репозитории был один файл, превышающий максимальный размер файла, разрешенный в моей системе. Я смог проверить это, пытаясь загрузить большой файл и превысив лимит размера файла в Debian.

После этого я отредактировал свой файл /etc/security/limits.conf, добавив в его конец следующие строки:

• жесткий fsize 1000000
• софт fsize 1000000

Чтобы действительно применить новые предельные значения, вам необходимо повторно войти в систему.

Из клона git я получал:

error: inflate: data stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

После перезагрузки моей машины я смог нормально клонировать репо.

Я отключил все загрузки, которые я делал в то же время, что, возможно, освободило место и очистило пропускную способность.

Похоже, что проблема с git-daemon была решена в v2.17.0 (проверено на неработающем v2 .16.2.1). т.е. Обходной путь выбора текста в консоли для «блокировки буфера вывода» больше не требуется.

Из https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt:

• Различные исправления для «git daemon». (позднее объедините ed15e58efe jk/daemon-fixes с maint).

Перепробовав большинство ответов здесь, я получил ошибку с SSH-клиентом PUTTY со всеми возможными сочетаниями.

Как только я переключился на OpenSSH, ошибка исчезла (удалите переменную среды GIT_SSH и перезапустите git bash).

Я использовал новую машину и новейшие версии git. На многих других/старых машинах (также AWS) он работал, как и ожидалось, с PUTTY без какой-либо настройки git.

У меня такая же проблема. РЕПО было слишком большим, чтобы его можно было загрузить через SSH. Как и рекомендовал @elin3t, я клонировал через HTTP/HTTPS и изменил УДАЛЕННЫЙ URL-адрес в .git/config, чтобы использовать SSH REPO.

У меня возникла та же проблема, что и ниже, когда я запускаю git pull

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Затем я проверил git status. Было так много незафиксированных изменений, что я решил проблему, зафиксировав и отправив все незафиксированные изменения.

Ни одно из приведенных выше решений не сработало для меня.

Решение, которое, наконец, сработало для меня, заключалось в переключении клиента SSH. Для переменной среды GIT_SSH было задано значение OpenSSH, предоставленное Windows Server 2019. Версия 7.7.2.1.

C:\Windows\System32\OpenSSH\ssh.exe

Я просто установил шпатлевку, 0.72

choco install putty

И изменил GIT_SSH на

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE

Я пробовал почти все предложения, сделанные здесь, но ни одно не сработало. Для нас проблема была темпераментной и становилась все хуже и хуже, чем больше становились репозитории (на нашем ведомом сборщике Jenkins Windows).

В итоге это была версия ssh, используемая git. Git был настроен на использование некоторой версии Open SSH, указанной в файле .gitconfig пользователей через переменную core.sshCommand. Удаление этой строки исправило это. Я считаю, что это связано с тем, что Windows теперь поставляется с более надежной/совместимой версией SSH, которая используется по умолчанию.

В моем случае я просто обновил свою версию OpenSSL. Более старые версии OpenSSL имеют уязвимости, а также не имеют новейших алгоритмов, которые могут понадобиться. На сегодняшний день команда openssl version показывает OpenSSL 1.1.1f 31 марта 2020 года.

Я пытался несколько раз после того, как установил буфер git, как я уже упоминал в вопросе, теперь он работает.

Итак, если вы столкнулись с этой ошибкой, выполните эту команду:

git config --global http.postBuffer 2M

а затем повторите попытку несколько раз.

Ссылка:

ошибка git push: сбой RPC; результат = 56, HTTP-код = 0

Качество сети имеет значение, попробуйте переключиться на другую сеть. Что мне помогло, так это изменение подключения к Интернету с высокоскоростного наземного широкополосного доступа Virgin Media на точку доступа на моем телефоне.

До этого я пробовал принятый ответ, чтобы ограничить размер клона, пробовал переключаться между 64- и 32-битными версиями, пытался отключить кеш файлов git, ни один из них не помог.

Затем я переключился на подключение через свой мобильный, и первый шаг (git clone --depth 1 ‹repo_URI›) удался. Вернулся к моему широкополосному доступу, но следующий шаг (git fetch --unshallow) также не удался. Итак, я удалил код, клонированный до сих пор, переключился на мобильную сеть, попробовал еще раз по умолчанию (git clone ‹repo_URI›), и это удалось без каких-либо проблем.

Хотя это не совсем такая же настройка, но у меня была эта проблема с общим ресурсом nfs, установленным в Ubuntu 20.04. Я не нашел никакого решения, поэтому я делюсь тем, как я его решил, надеясь, что смогу кому-то помочь.

Сообщение об ошибке было (иногда с/без предупреждения):

warning: die() called many times. Recursion error or racy threaded death!
fatal: premature end of pack file, 29 bytes missing
fatal: premature end of pack file, 24 bytes missing
fatal: index-pack failed

Мелкий клон Git, отключение сжатия и т. д. не решили проблему.

Когда я смонтировал общий ресурс с nfsvers=4.2 вместо nfsvers=4.0, проблема исчезла.

Следующий шаг отлично работает для меня.

git clone --depth 1 https://github.com/user/rep.git

Это сработало для меня, настроив сервер имен Google, поскольку стандартный сервер имен не был указан, а затем перезапустил сеть:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

Если вы работаете в Windows, вы можете проверить сбой git clone с ошибкой index-pack?.

По сути, после запуска вашей команды git.exe daemon ... выберите текст в этом окне консоли. Повторите попытку извлечения/клонирования, сейчас это может сработать!

См. этот ответ для получения дополнительной информации.

Убедитесь, что на вашем диске достаточно свободного места

Ни один из них не работал у меня, но использование встроенного инструмента Heroku помогло.

heroku git:clone -a myapp

Документация здесь: https://devcenter.heroku.com/articles/git-clone-heroku-app