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