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


271

Я погуглил и нашел много решений, но ни одно не работает для меня.

Я пытаюсь клонировать с одной машины, подключившись к удаленному серверу, который находится в сети LAN.
Выполнение этой команды с другого компьютера вызывает ошибку.
Но запустить команду SAME clone с помощью git: //192.168.8.5 ... на сервере все в порядке и успешно.

Любые идеи ?

user@USER ~
$ git clone  -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed

Я добавил этот конфиг в, .gitconfigно также не помог.
Использование git версии 1.8.5.2.msysgit.0

[core]
    compression = -1

8
Я сталкивался с этой проблемой в течение 2-3 дней, когда пытался клонировать из VPN. в моем случае проблема заключалась в пропускной способности сети. я исправил клонированием в высокоскоростной сети.
Авиджит Нагаре,

1
Я также заметил, что это связано с сетью.
чудо

1
Я получил эту ошибку, потому что мои друзья не очень хорошо знают git и загружают много изображений в репозиторий! =))
Clite Tailor

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

Ответы:


506

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

git config --global core.compression 0

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

git clone --depth 1 <repo_URI>

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

git fetch --unshallow 

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

git fetch --depth=2147483647

Теперь сделайте обычную тягу:

git pull --all

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


6
Спасибо, это сработало отлично. Я попытался изменить http.postbuffer, который не работал, но после выполнения, как указано в этом ответе, он работал отлично. Я не использовал строку «git fetch --depth = 2147483647», но использовал остальные.
Ник Бенедикт

2
@ EthenA.Wilson После этого вам нужно будет передать удаленный URL для хранилища. Например git clone --depth 1 git@host:user/my_project.git.
Натан Гулд

6
@Jose A. - Я столкнулся с этой проблемой, когда был на более новой версии msysgit. Если вы используете msysgit, попробуйте старую версию (<= 1.8.3). В противном случае попробуйте git fetch --depth 1000 (затем 2000 и т. Д., Постепенно увеличиваясь, пока все файлы не будут извлечены).
месте

2
@Jose A. - Также взгляните на это: stackoverflow.com/questions/4826639/…
ingyhere

2
Привет, дорогой друг. Спасибо за ваше отличное решение. Но последнее git pull --allне работает. Из-за git clone --depth 1будет установлен диапазон выборки только одной ветви. Поэтому мы должны сначала отредактировать .git / config.
Пинч

93

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

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

Это сработало для меня - хотя мне все еще нужно было несколько попыток, но без этого изменения прерывание составило 30%, потом 75% ... и однажды оно возросло до 100% и сработало. :)
Песчу

Должен быть выбранный ответ
Асим Касымзаде

На windows с git 2.19 это исправлено. В частности добавление параметров, связанных с пакетом.
Καrτhικ

Работал! Спасибо!
Guille Acosta

все еще не работает для меня remote: Enumerating objects: 43, done. remote: Counting objects: 100% (43/43), done. remote: Compressing objects: 100% (24/24), done. error: inflate returned -55/26) fatal: unpack-objects failed
Дживан Чайтанья

26

наконец решено 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.


3
Нужно было запустить git repackв сочетании с этим решением, и тогда это сработало.
erikH

Это сработало, даже не пробовал другие решения, потому что это самое короткое и элегантное решение. должен быть принят ответ!
Метабластер

Это работает и для меня через VPN и корпоративный прокси. --compression 0не работали и не делали все .gitconfigизменения, предложенные выше.
Терренс Брэннон

20

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

Мелкий клон

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

git config --global core.compression 0

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

git clone --depth 1 <repo_URI>

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

git fetch --unshallow

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

git fetch --depth=2147483647

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

git pull --all

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

откройте ваш файл git config ( .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 сейчас потянет все ваши удаленные ветви


Это работает, но я оставил сжатие до 9, а не 0, что не удалось.
метабластер

9

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

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

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

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


6

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

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

git clone <your_http_or_https_repo_url> 

иначе, если вы тянете на существующий репо, сделайте это с

git remote set-url origin <your_http_or_https_repo_url>

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


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

Да! Это работа для меня, у меня есть репозиторий 4gb +, и единственное решение, которое я получил, было это!
elin3t

2
Это работает для меня, спасибо! Клонируйте, httpsа затем установите пульт на ssh.
Туан

1
Мне бы очень хотелось знать, почему это сработало. Есть ли в протоколе SSH что-то, что подавляет большие объекты, чего нет у HTTPS? Это проблема транспортного уровня?
Бдетвейлер

6

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

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


Для меня не было много доступной памяти, освободив немного и попытавшись решить эту проблему.
Мартин Кэссиди

4

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

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


4

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

[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

2

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

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

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

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

1

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

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

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

Когда core.packedGitLimitпревышено, git закроет пакеты.
Если параллельно с извлечением происходит операция перепаковки, извлечение может открыть пакет, а затем принудительно закрыть его из-за попадания packGitLimit.
Затем перепаковка может удалить пакет из-под выборки, что приведет к сбою выборки.

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

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



1

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

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

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


1

Тангенциально связан и полезен только в том случае, если у вас нет прав root и вы извлекаете 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

1

У меня были такие же журналы ошибок, используя git (v2.17.1) поверх ssh. В моем случае решение таково:

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

Смотрите документацию git-gc: https://git-scm.com/docs/git-gc. .

Например:

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 clone git@my_server_url.com:my_repo_name

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


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

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

Существует вероятность того, что переполнение буфера не произойдет.


0

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

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


0

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


0

Кажется, проблема 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).

0

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

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

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


что ты имеешь в виду Тед?
Vishav Premlall

этот «ответ» должен был быть комментарием к ответу @ingyhere.
mc0e

0

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

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

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


0

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


0

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


0

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

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


0

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

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


-1

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

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

-1

Из мерзавца-клона я получил:

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

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


В первый раз я не могу поверить, что просто перезагрузка компьютера может решить эту проблему, но я перепробовал все сообщения, которые не могут работать. поэтому я решил перезагрузить мою машину, это мое последнее решение для меня. мне повезло, когда машина запускается, я пытаюсь снова клонировать. Я не могу в это поверить. Это работает !!!!!!!
Открой

-1

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

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

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



Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.