Фатальный: ранний EOF фатальный: индекс-пакет не прошел

Ответ 1

Сначала отключите сжатие:

git config --global core.compression 0

Далее, сделайте частичный клон, чтобы усечь количество информации:

git clone --depth 1 <repo_URI>

Когда это работает, зайдите в новый каталог и извлеките остальную часть клона:

git fetch --unshallow 

или, поочередно,

git fetch --depth=2147483647

Теперь сделайте регулярное нажатие:

git pull --all

Я думаю, что в версиях 1.8.x есть сбой с msysgit, что усугубляет эти симптомы, поэтому еще один вариант - попробовать более раннюю версию git (< = 1.8.3, я думаю).

Ответ 2

Эта ошибка может возникнуть для потребностей памяти git. Вы можете добавить эти строки в свой глобальный конфигурационный файл git, который .gitconfig в $USER_HOME, чтобы исправить эту проблему.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

Ответ 3

окончательно решен с помощью git config --global core.compression 9

Из потока вопросов BitBucket:

Я пытался почти пять раз, и это все еще происходит.

Тогда я попытался использовать лучшее сжатие, и это сработало!

git config --global core.compression 9

Из документации Git:

core.compression
Целое число -1.. 9, указывающее уровень сжатия по умолчанию. -1 - это значение по умолчанию для zlib.
0 означает отсутствие сжатия, а 1..9 - это различные компромиссы между скоростью и размером, 9 - самый медленный.
Если установлено, это обеспечивает значение по умолчанию для других переменных сжатия, таких как core.looseCompression и pack.compression.

Ответ 4

Как сказал @ingyhere:

Мелкий клон

Сначала отключите сжатие:

git config --global core.compression 0

Далее, давайте сделаем частичный клон, чтобы обрезать количество информации, поступающей вниз:

git clone --depth 1 <repo_URI>

Когда это сработает, перейдите в новый каталог и получите оставшуюся часть клона:

git fetch --unshallow

или, поочередно,

git fetch --depth=2147483647

Теперь сделайте тягу:

git pull --all

Тогда для решения проблемы вашей локальной ветки только мастер слежения

откройте ваш файл конфигурации git (.git/config) в редакторе по вашему выбору

где сказано:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

изменить линию

fetch = +refs/heads/master:refs/remotes/origin/master

в

fetch = +refs/heads/*:refs/remotes/origin/*

Сделай git fetch и git сейчас потянет все твои удаленные ветки

Ответ 5

В моем случае это было очень полезно:

git clone --depth 1 --branch $BRANCH $URL

Это ограничит выезд только указанной ветвью, следовательно, ускорит процесс.

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

Ответ 6

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

Освобождение памяти (в данном случае: разрешение компиляции заканчивается) и попытка снова работать для меня.

Ответ 7

Я пробовал все эти команды, и никто не работает для меня, но то, что работает, это изменение git_url на http вместо ssh

Если команда clone делает:

git clone <your_http_or_https_repo_url> 

else, если вы используете существующий репо, сделайте это с помощью

git remote set-url origin <your_http_or_https_repo_url>

надеюсь, что это поможет кому-то!

Ответ 8

В моем случае это была проблема подключения. Я был подключен к внутренней сети wifi, в которой у меня был ограниченный доступ к ресурсам. Это позволяло git делать выборку, но в определенное время она разбилась. Это означает, что это может быть проблема сетевого подключения. Проверьте, все ли работает правильно: антивирус, брандмауэр и т.д.

Поэтому ответ elin3t важен потому, что ssh повышает производительность загрузки, поэтому можно избежать проблем с сетью.

Ответ 9

Настройка ниже конфигурации не работает для меня.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

Как и в предыдущем комментарии, возможно, проблема с памятью в git. Таким образом, я стараюсь уменьшить рабочие потоки (с 32 до 8). Так что он не будет получать много данных с сервера одновременно. Затем я также добавляю "-f" для синхронизации других проектов.

-f: Proceed with syncing other projects even if a project fails to sync.

Тогда все отлично работает.

repo sync -f -j8

Ответ 10

Обратите внимание, что Git 2.13.x/2.14 (Q3 2017) действительно увеличивает значение по умолчанию core.packedGitLimit, которое влияет на git fetch:
Предельное значение упакованного по умолчанию git было увеличено на более крупных платформах (от 8 до 32 ГБ), чтобы сохранить "git fetch" из (восстанавливаемого) отказа, а "gc" - параллельная работа.

См. commit be4ca29 (20 апреля 2017 г.) Дэвид Тернер (csusbdt).
Помог: Джефф Кинг (peff).
^{(слияние Junio ​​C Hamano - gitster - в commit d97141b, 16 мая 2017 года)}

Увеличение core.packedGitLimit

Когда core.packedGitLimit превышено, Git закроет пакеты.
Если операция повторной обработки происходит параллельно с извлечением, выборка может открыть пакет, а затем будет принудительно закрыть его из-за того, что он упал в GitLimit. После этого repack может удалить пакет из-под выборки, в результате чего выборка завершится неудачей.

Увеличьте значение core.packedGitLimit по умолчанию, чтобы предотвратить это.

В текущих 64-разрядных машинах x86_64 доступно 48 бит адресного пространства.
Похоже, что 64-битные ARM-машины не имеют стандартного количества адресного пространства (то есть, оно зависит от производителя), а машины IA64 и POWER имеют полные 64 бит.
Таким образом, 48 бит - это единственный предел, который мы можем разумно заботиться. Мы резервируем несколько бит 48-битного адресного пространства для использования ядра (это не строго необходимо, но лучше быть в безопасности) и использовать до остальных 45.
Репозиторий Git в ближайшее время будет находиться рядом с этим большим количеством, поэтому это должно предотвратить отказ.

Ответ 11

Предыдущий ответ рекомендует установить 512 м. Я бы сказал, что есть причины думать, что это неэффективно в 64-битной архитектуре. Документация для core.packedGitLimit гласит:

По умолчанию 256 МБ на 32-битных платформах и 32 ТБ (практически без ограничений) на 64-битных платформах. Это должно быть разумно для всех пользователей/операционных систем, за исключением самых крупных проектов. Вам, вероятно, не нужно корректировать это значение.

Если вы хотите попробовать его, проверьте, установлен ли он, а затем удалите настройку:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

Ответ 12

В моем случае ничего не работало, когда протокол был https, затем я переключился на ssh и гарантировал, что я вытащил репо из последней фиксации, а не всей истории, а также конкретной ветки. Это помогло мне:

git clone --depth 1 "ssh:.git" --branch "specific_branch"

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

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

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

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 изменениями в их истории. После этого вы можете выполнить любую команду просто отлично и с нормальной скоростью.

Ответ 16

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

Ответ 17

Проблема 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).

Ответ 18

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

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

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

Ответ 19

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

Ответ 20

У меня та же проблема, что и ниже, когда я запускаю 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 Было так много незафиксированных изменений, что я исправил проблему, зафиксировав и перенеся все незафиксированные изменения.

Ответ 21

Ни одно из приведенных выше решений не помогло мне.

Решение, которое наконец-то сработало для меня, - переключение 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

Ответ 22

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

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

Ответ 23

Если вы находитесь в Windows, вы можете проверить, что git не работает с клонированием с индексом-индексом " не удалось?.

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

Подробнее см. этот ответ.

Ответ 24

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

heroku git:clone -a myapp

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