фатальний: ранній EOF фатальний: індекс-пакет не вдався

Я переглянув Google і знайшов багато рішень, але жодна робота не для мене.

Я намагаюся клонуватися з однієї машини, підключившись до віддаленого сервера, який знаходиться в мережі LAN.
Запуск цієї команди з іншої машини викликає помилку.
Але запустити команду клонування SAME за допомогою 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

Спочатку вимкніть стиснення:

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, я думаю).

Ця помилка може виникнути для пам'яті git. Ви можете додати ці рядки в глобальної конфігурації мерзотник файл, який знаходиться .gitconfigв $USER_HOME, для того , щоб виправити цю проблему.

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

нарешті вирішений 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.

Як сказав @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 file ( .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 зараз потягне всі ваші віддалені гілки

У моєму випадку це було дуже корисно:

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

Це обмежить касу лише згаданою філією, отже, прискорить процес.

Сподіваюсь, це допоможе.

Я спробував усі ці команди, і жодна для мене не працює, але те, що працює, було змінити git_url на http, а не ssh

якщо команда клонування виконайте:

git clone <your_http_or_https_repo_url> 

інакше, якщо ви тягнете за існуючим репо, зробіть це з

git remote set-url origin <your_http_or_https_repo_url>

сподіваюся, що це допоможе комусь!

Я отримав цю помилку, коли у Git закінчилося пам’ять.

Звільнити деяку пам’ять (в даному випадку: дозволити роботу над складанням) і спробувати знову працював на мене.

У моєму випадку це була проблема з підключенням. Мене підключили до внутрішньої мережі Wi-Fi, в якій я мав обмежений доступ до ресурсів. Це давало можливість git зробити результат, але в певний час він зазнав краху. Це означає, що це може бути проблема з підключенням до мережі. Перевірте, чи все працює належним чином: антивірус, брандмауер тощо.

Відповідь elin3t важлива, тому що ssh покращує продуктивність завантаження, щоб уникнути проблем з мережею

Налаштування нижче налаштувань для мене не працюють.

[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

Попередня відповідь рекомендує встановити 512 м. Я б сказав, що є причини вважати, що це непродуктивно для 64-бітової архітектури. Документація core.packedGitLimit каже:

За замовчуванням 256 Мб на 32-бітних платформах та 32 TiB (фактично необмежений) на 64-бітних платформах. Це має бути розумним для всіх користувачів / операційних систем, за винятком найбільших проектів. Можливо, вам не потрібно коригувати це значення.

Якщо ви хочете спробувати його, перевірте, чи у вас його встановлено, а потім видаліть налаштування:

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

Зауважте, що Git 2.13.x / 2.14 (Q3 2017) дійсно підвищує типовий стан, core.packedGitLimitякий впливає git fetch:
Типовий ліміт значення упакованого git було підвищено на більших платформах ( з 8 Гб до 32 Гб ), щоб зберегти " git fetch" від (відновлюваного) збою поки " gc" працює паралельно.

Див. Комісію be4ca29 (20 квітня 2017) від Девіда Тернера ( csusbdt) .
Допоможи: Джефф Кінг ( peff) .
^{(Об'єднано Хуніо С Хамано - gitster- у комітеті d97141b , 16 травня 2017 р.)}

Збільшити core.packedGitLimit

Коли core.packedGitLimitбуде перевищено, git закриє пакети.
Якщо паралельна операція з перезапуском відбувається паралельно із завантаженням, він може відкрити пакет, а потім буде змушений закрити його через попадання пакетаGitLimit.
Потім упаковка може видалити пакунок з-під завантаження, внаслідок чого збір даних вийде з ладу.

Збільште core.packedGitLimitзначення за замовчуванням, щоб запобігти цьому.

На нинішніх 64-бітних x86_64 машинах доступно 48 біт адресного простору.
Виявляється, що 64-бітні машини ARM не мають стандартної кількості адресного простору (тобто він залежить від виробника), а машини IA64 та POWER мають 64 біти.
Отже, 48 біт - це єдиний ліміт, про який ми можемо з розумом піклуватися. Ми залишаємо кілька біт 48-бітного адресного простору для використання ядра (це не обов'язково, але краще бути безпечним), а також використовувати до решти 45.
Жодне сховище git не буде ніде поблизу цього великого в будь-який час незабаром, тому це повинно запобігти невдачі.

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

Тут розміщено тут: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Ви можете запустити його за допомогою наступного рядка:

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

У моєму випадку проблема полягала не в жодному з параметрів конфігурації git, а в тому, що в моєму сховищі був один файл, що перевищує максимальний розмір файлу, дозволений у моїй системі. Мені вдалося перевірити це, намагаючись завантажити великий файл та отримати "Перевищений розмір файлу" на Debian.

Після цього я відредагував мій /etc/security/limits.conf файл, додавши до кінця його наступні рядки: * hard fsize 1000000 * soft fsize 1000000

Щоб фактично "застосувати" нові граничні значення, вам потрібно повторно ввійти

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

Якщо клон git не вдається 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

У мене були такі ж журнали помилок, використовуючи git (v2.17.1) над ssh. У моєму випадку рішення:

1. Увійдіть до голого сховища мого сервера.
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

Є ймовірність, що переповнення буфера не відбудеться.

У моєму випадку нічого не спрацювало, коли протокол був https, тоді я перейшов на ssh і переконався, я витягнув репо з останнього комітету і не всієї історії, а також конкретної галузі. Це допомогло мені:

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

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

Проблема 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 demon". (злиття ed15e58efe jk / daemon-fixes пізніше для maint).

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

Кожна команда працює набагато повільніше, ніж зазвичай, після чого стискається після стискання об'єктів.

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 правками в їх історії. Після цього ви можете виконати будь-яку команду просто добре і на нормальній швидкості.

Спробувавши більшість відповідей тут, я отримав помилку з PUTTY SSH Client з усіма можливими сузір’ями.

Як тільки я перейшов на OpenSSH, помилка зникла (видаліть змінну середовища GIT_SSH та перезавантажте git bash).

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

У мене є та ж проблема. РЕПО був занадто великий, щоб завантажити його через SSH. Так само, як @ elin3t рекомендував, я клонував HTTP / HTTPS і змінив REMOTE 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

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

Це в кінцевому підсумку стала версією ssh, що використовується git. Git був налаштований на використання деякої версії Open SSH, зазначеної у файлі .gitconfig через змінну core.sshCommand. Видалення цієї лінії виправлено. Я вважаю, це тому, що Windows тепер постачається з більш надійною / сумісною версією SSH, яка використовується за замовчуванням.

Це працювало для мене, налаштовуючи сервер імен Googles, оскільки не було вказано стандартного сервера імен, після чого слід перезапустити мережу:

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

Від клона git я отримував:

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

Після перезавантаження машини я зміг клонувати репо-штрафи.

Якщо ви працюєте в Windows, можливо, ви хочете перевірити, чи не спрацьовує git clone, а "index-pack" не вдалося? .

Після запуску git.exe daemon ...команди виберіть текст із цього вікна консолі. Повторіть витягування / клонування, це може просто працювати зараз!

Дивіться цю відповідь для отримання додаткової інформації.

Переконайтеся, що у вашого диска залишилось достатньо місця

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

heroku git:clone -a myapp

Документація тут: https://devcenter.heroku.com/articles/git-clone-heroku-app