git clone problem: твърде голямо репо? (50 м)

Имах проблем с невъзможността да клонирам git repo. Започва да работи и след това се отменя по средата. Текущият ми размер на git repo е 53,7 MB Версията на 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
45m размерът на единичен ангажимент ли е? Това е доста огромно, IIRC, github има ограничение от максимален размер от 50 MB за ангажиране. Ако имате толкова голям ангажимент - това трябва да обясни защо извличането/изтеглянето/клонирането се прекъсва всеки път. Моето предложение би било да намалите този ангажимент. Що се отнася до това как всъщност да се намали размера на съществуващ ангажимент... - Мисля, че ще трябва да зададете друг въпрос. - person Anshul Goyal; 31.07.2014
comment
@tdm Също така, сега, след като препрочетох въпроса ви, не става въпрос само за размера на репото, а и за размера на отделните ангажименти. И ето е проблемът, който споменах в по-ранен коментар. - person Anshul Goyal; 31.07.2014
comment
Да, така бих си помислил. Не знаех, че дори има ограничение за максимален размер на git commit. Ще разгледам разделянето на моя ангажимент в този случай. Благодаря отново за цялата помощ. - 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