сбой git clone с "index-pack"

Question

Итак, я создал удаленное репо, которое не голое (потому что мне нужен redmine, чтобы иметь возможность его читать), и он настроен для совместного использования с группой (поэтому git init --shared = group). Я смог подтолкнуть к удаленному репо, и теперь я пытаюсь его клонировать.

Если я клонирую это по сети, я получаю это:

remote: Counting objects: 4648, done.
remote: Compressing objects: 100% (2837/2837), done.
error: git-upload-pack: git-pack-objects died with error.B/s  
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

Я могу клонировать его локально без проблем, и я запустил «git fsck», который сообщает только о некоторых висячих деревьях / каплях, которые, как я понимаю, не являются проблемой. Что может быть причиной этого? Я все еще могу вытащить его, но не клонировать. Я должен отметить, что удаленная версия git - 1.5.6.5, а локальная - 1.6.0.4

.

Я попытался клонировать свою локальную копию репо, вычистить папку .git и нажать на новое репо, затем клонировать новое репо, и я получил ту же ошибку, из-за чего я понял, что это может быть файл репозиторий, вызывающий сбой git-upload-pack ...

Edit: У меня есть несколько оконных бинарных файлов в репозитории, потому что я просто собрал модули python, а затем вставил их туда, чтобы всем остальным не пришлось их создавать. Если я удалю бинарные файлы Windows и перейду к новому репо, я смогу снова клонировать, возможно, это даст подсказку. Попытка точно определить, какой файл вызывает проблему.

Answer 1

Я решил эту проблему так: мой демон git работает на Windows, а клиенты на других компьютерах.

Я нашел обходной путь (но он будет работать только на Windows).

Запуск git daemon с многословным из cmd.exe:

"C:\Program Files\Git\bin\sh.exe" --login -i -c 'git.exe daemon --verbose  '

Не проверено, работает ли оно напрямую в git bash. Может быть, так и будет.

Затем (перед запуском любого клона, вытащить, извлечь, ...) выберите текст в окне (примечание: «Режим быстрого редактирования» должен быть включен (находится в: cmd.exe -> Свойства (нажмите верхний левый угол окна cmd) -> Edit Options)), в котором работает git daemon. Это не позволит ему печатать дальнейшие сообщения в этом окне.

Когда выходной поток демона git блокируется таким образом, ошибка не возникает

Answer 2

У меня такая же проблема, как и у вас; сообщение об ошибке при клонировании я:

Cloning into test...
remote: Counting objects: 6503, done.
remote: Compressing objects: 100% (4519/4519), done.
Connection to git.myhost.im closed by remote host.| 350 KiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

В моем случае причина в том, что размер моего хранилища (200 МБ) больше, чем объем памяти моего git сервера (128 МБ). Когда я клонирую с сервера git, я использую команду top на своем сервере, которая показывает, что использование памяти скоро превысит 128M.

Когда я использую другой сервер с памятью 4G, с git clone все в порядке. Вы также можете попробовать добавить больше места подкачки к своему серверу.

Answer 3

Жалуется "git gc"?

Answer 4

У меня была такая же проблема. Я также предположил, что это связано с тем, что я использую режим text / CRLF для созданных файлов. И действительно, после переключения CygWin в режим UNIX / бинарный перевод строки все работает нормально.

См:

• http://cygwin.com/cygwin-ug-net/using-textbinary.html
• http://www.sourceware.org/cygwin/cygwin-ug-net/using-utils.html#mount

Кстати, для меня самый простой способ переключить режим файла - это отредактировать / etc / fstab переключиться с

нет / cygdrive текст cygdrive, posix = 0, пользователь 0 0

до

нет / cygdrive бинарный cygdrive, posix = 0, пользователь 0 0

Answer 5

Используйте переменную окружения GIT_TRACE для получения отладочной информации. Установите значение «1» для трассировки до stderr или абсолютный путь для трассировки в файл.

Answer 6

У меня тоже были проблемы с cygwin git, ошибка: fatal: index-pack failed,

Мне удалось решить эту проблему, создав монтирование для моих проектов и установив его в бинарный режим. так как мой /c установлен в текстовый режим.

Добавить Cygwin's к /etc/fstab:

c:/work/Projects /projects some_fs binary 0 0

запустите mount -a, чтобы смонтировать все диски.

Вы должны быть в /projects, чтобы работать с cygwin git, /c/work/Projects не удастся.

Не уверен, что это сработает для вас.

Answer 7

Я столкнулся с этой проблемой, клонируя репозиторий github с github.com, запустив git 2.13 на SLES 12 SP3. Пробовал обновлять git до последней версии (v2.21 в то время), но это не помогло решить проблему. Попытка установки параметров конфигурации git и многих других, но безуспешно.

В конце концов, я сделал это вручную.

• создал каталог вручную .. mkdir somedir
• Ран git init для установки каталога для GIT.
• Вручную добавили репозиторий github в качестве источника git remote add origin http://github.com/git/git
• Побежал git fetch, чтобы взять пакет. Эта задача завершилась ошибкой, но осталась за пакетом извлеченных, но плохих в .git/objects/pack/tmp_pack_XXXXXX
• используется cat .git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r для извлечения всех допустимых объектов.
• Снова запустил git fetch, чтобы что-то пропустить (например, ветки и метки) из предыдущих попыток. Никакая упаковка / объекты не нужны, потому что все они были распакованы.
• Наконец, git checkout master, чтобы HEAD указывал на что-то реальное.

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

Answer 8

У меня была эта проблема или близка к ней, но я не видел решения моего дела ни в одной из этих тем.

В моем случае проблема заключалась в брандмауэре. Клонирование небольших репозиториев работало в любом случае, но большие не удавались. Так что, если больше ничего не помогает, стоит проверить настройки брандмауэра.

Answer 9

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

Answer 10

Я решаю эту проблему путем исправления разрешения папки:

sudo chmod 777 -R Your_folder