git clone issue: слишком большое репо? (50 м)

Возникла проблема с невозможностью клонировать репозиторий git. Он начинает работать, а затем прерывается на полпути. Мой текущий размер репозитория git составляет 53,7 МБ. Версия Git - 1.7.12.4 на сервере и на моем удаленном компьютере.

Ошибка ниже:

MacBook-Pro:htdocs macbook$ git clone [email protected]:~/opt/git/myrepo.git 
Cloning into 'myrepo'...
[email protected]'s password:
remote: Counting objects: 8888, done.
remote: Compressing objects: 100% (7185/7185), done.
Write failed: Broken pipe267/8888), 1.03 MiB | 1001.00 KiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

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

Я добавил это без везения:

[core]
    compression = -1
[pack]
    windowMemory = 10m
    packSizeLimit = 20m

Я попытался поднять их до более высоких значений. Не повезло

Я также пробовал запускать git gc --aggressive и git gc --prune в удаленном репо.

Я видел этот пост, но мой не такой большой (1g +). Также см. люди, имеющие проблемы с версиями git не совпадает, но это не тот случай, когда эфир.


person Josh    schedule 30.07.2014    source источник


Ответы (2)


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

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

По сути, инициализируйте пустой репозиторий

cd repo_name && git init

Добавить исходное репо как удаленное в это репо

git remote add origin url/to/repo

А теперь сделайте git fetch.

Таким образом, даже если ваш клон сломается посередине, fetch позаботится о том, чтобы доставить невыгруженные объекты только при следующем запуске.


Кроме того, вы можете проверить решения здесь и здесь.

person Anshul Goyal    schedule 30.07.2014
comment
Этот метод действительно работает. Я действительно хочу выяснить, почему это происходит. Было бы проще дать кому-нибудь ссылку на клон, чтобы он начал работать над ней. - person Josh; 30.07.2014
comment
@tdm Вы проверили другие упомянутые мною решения здесь и здесь? Самая простая причина может заключаться в перегрузке сети, прерывающей операцию клонирования посередине, что заставляет вас снова начинать с нуля. - person Anshul Goyal; 30.07.2014
comment
Пропустил. Ответ на ссылку 1) git clone --depth 1 и git fetch –-depth=2147483647 оба работают с клоном, когда я делаю git pull --all, он говорит, что все обновлено. Я заметил, что в моем удаленном репо отображается только моя исходная основная ветка. Это не моя ветка разработки, в которой у меня есть почти все. Как будто она не может найти мою ветку разработки, что, кажется, является проблемой, вызывающей перегрузку сети. - person Josh; 30.07.2014
comment
Ответ на ссылку 2) Я вернулся к git 1.7.1 на сервере и на своей машине. Тем не менее проблема сохраняется. Я повторно попробовал шаги в ссылке 1, которые вы предоставили также при работе на 1.7.1. - person Josh; 30.07.2014
comment
@tdm Как вы проверяете ветки в удаленном репо? Это репозиторий gihub / bitbucket / gitlab? - person Anshul Goyal; 30.07.2014
comment
Все делаю в терминале. Мне нужно было объединить ветку develop в master. Я не знаю, почему моя ветка develop не отображается в новом клоне, я позабочусь об этом позже. --- Теперь это та же проблема, что и раньше. git pull в моем новом клоне git на master он начинает тянуть, а затем останавливается с теми же ошибками, что и раньше. Я беру фиксацию после того, как добавил свои файлы Drupal CMS, всего около 45 миллионов. - person Josh; 31.07.2014
comment
45 м - размер одного коммита? Это довольно много, IIRC, github имеет ограничение на максимальный размер 50 МБ для фиксации. Если у вас есть такой большой коммит - это должно объяснить, почему выборка / извлечение / клонирование каждый раз прерывается. Я предлагаю сократить эту фиксацию. Что касается того, как на самом деле уменьшить размер существующего коммита ... - Думаю, вам придется задать другой вопрос. - person Anshul Goyal; 31.07.2014
comment
@tdm Кроме того, теперь, когда я перечитал ваш вопрос, дело не только в размере репо, но и в размере отдельных коммитов. И здесь проблема, о которой я упоминал в предыдущем комментарии. - person Anshul Goyal; 31.07.2014
comment
Да, я бы так подумал. Я не знал, что есть даже ограничение на максимальный размер коммита git. В этом случае я рассмотрю разделенный коммит. Еще раз спасибо всем за помощь. - person Josh; 31.07.2014
comment
после git fetch, используя git pull origin master, вы получите все файлы - person X.C.; 25.11.2020

Также попробуйте увеличить свой postBuffer

git config --global http.postBuffer 1048576000

person peterholcomb    schedule 30.07.2015