Git Не удалось выполнить клонирование с "index-pack"?

Итак, я создал удаленное репо, которое не было голым (потому что мне нужно, чтобы 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 и нажав на новое репо, затем клонируя новое репо, и я получаю ту же ошибку, что заставляет меня думать, что это файл в repo, что приводит к сбою git -upload-pack...

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

Ответ 1

Как я решил эту проблему: My git daemon работает в Windows, а клиенты находятся на других компьютерах.

Я нашел обходное решение (но оно будет работать только в окнах).

Запустите демон git с подробным из cmd.exe:

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

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

Затем (перед запуском любого клона, pull, fetch,...) выберите текст в окне (обратите внимание: "Режим быстрого редактирования" должен быть включен (можно найти в: cmd.exe → Свойства (щелкните верхний левый угол вашего окна cmd) → Параметры редактирования)), в котором запускается демон git. Это предотвратит его печать любых последующих сообщений в этом окне.

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

Ответ 2

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

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

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

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

Ответ 3

Спрашивает ли "git gc"?

Ответ 4

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

См:

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

none/cygdrive cygdrive text, posix = 0, user 0 0

к

none/cygdrive cygdrive binary, posix = 0, пользователь 0 0

Ответ 5

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

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

Добавьте cygwin в /etc/fstab:

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

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

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

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

Ответ 6

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

Ответ 7

Я обновил свой клиентский компьютер git до той же версии, что и сервер, и это исправлено для меня.

Ответ 8

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

git config --global pack.packSizeLimit 50m
git config --global pack.windowMemory 50m
git config --global core.compression 9

Ответ 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).

Ответ 10

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

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

Ответ 11

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

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

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

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

Ответ 12

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

sudo chmod 777 -R Your_folder