Каков самый быстрый способ клонирования репозитория git через быстрое сетевое соединение?

У меня есть ситуация с относительно большим репозиторием git, расположенным на пожилом, медленном хосте в моей локальной сети, где требуется довольно много времени, чтобы сделать первоначальный клон.

ravn@bamboo:~/git$ git clone gitosis@gitbox:git00
Initialized empty Git repository in /home/ravn/git/git00/.git/
remote: Counting objects: 89973, done.
remote: Compressing objects: 100% (26745/26745), done.
remote: Total 89973 (delta 50970), reused 85013 (delta 47798)
Receiving objects: 100% (89973/89973), 349.86 MiB | 2.25 MiB/s, done.
Resolving deltas: 100% (50970/50970), done.
Checking out files: 100% (11722/11722), done.
ravn@bamboo:~/git$

нет никаких изменений конфигурации Git в gitosis.

есть ли способ ускорить получение бита до того, на что способна сеть?

EDIT: мне нужно, чтобы новые репозитории были правильно связаны с вышестоящим репозиторием. К моему понимание этого требует, чтобы git делал клонирование, и, следовательно, сырое копирование бит вне git не будет работать.

21
git git-clone performance

4 ответов

PS. Справедливое предупреждение:

git обычно считается невероятно быстрым. Вы должны попробовать клонировать полное РЕПО из darcs, bazaar ,hg (не дай бог: TFS или subversion...). Кроме того, если вы регулярно клонируете полные РЕПО с нуля, вы все равно будете делать что-то неправильно. Вы всегда можете просто git remote update и сделать дополнительные изменения.

для различных других способов сохранить полное РЕПО в синхронизации см., например,

(содержат ссылки на другие соответствующие сообщения SO)

тупой копией

как уже упоминалось, вы можете просто скопировать репозиторий с "тупой" передачей файлов.

это, безусловно, не будет тратить время на сжатие, переупаковку, deltifying и / или фильтровать.

плюс, вы получите

может не будьте тем, что вам нужно, но приятно осознавать этот факт

Bundle

git clone по умолчанию оптимизирует пропускную способность. Поскольку git clone, по умолчанию, не зеркала все филиалы (см. --mirror) не имеет смысла просто сбрасывать файлы пакета как есть (потому что это отправит, возможно, больше, чем требовать.)

при распространении в по-настоящему крупные!--20--> количество клиентов, рассмотрите возможность использования Пучков.

если вы хотите быстрый клон без серверной стоимости,git way и bundle create. Теперь вы можете распространять пакет без участия сервера. Если ты это имеешь в виду ... --6-- > включает в себя больше, чем просто git clone рассмотрим, например,bundle ... master для уменьшения объема.

git bundle create snapshot.bundle --all # (or mention specific ref names instead of --all)

и вместо этого распространите пакет моментальных снимков. Это лучшее из обоих миров, в то время как, конечно, вы не получите элементы из списка пуль выше. На приемном конце, просто 

git clone snapshot.bundle myclonedir/

сжатие конфиги

вы можете посмотреть на снижение нагрузки на сервер путем уменьшения / удаления сжатия. Взгляните на эти настройки конфигурации (я предполагаю pack.compression может помочь вам снизить нагрузку на сервер)

ядра.сжатие

An целое число -1..9, указывающее уровень сжатия по умолчанию. -1 это как zlib по умолчанию. 0 означает отсутствие сжатия, а 1..9 различные скорости/компромиссы размер 9 быть медленным. Если задано, это предоставляет значение по умолчанию для других переменных сжатия, таких как ядро.loosecompression и пакет.компрессия.

ядра.loosecompression

целое число -1..9, указывающее уровень сжатия для объектов, которые не находятся в файле пакета. -1 это как zlib по умолчанию. 0 означает отсутствие сжатие и 1..9 различные скорости/компромиссы размер 9 быть медленным. Если не установлено, по умолчанию ядро.компрессия. Если это не задано, по умолчанию 1 (лучшая скорость).

пакета.сжатие

целое число -1..9, указывающее уровень сжатия для объектов в файле пакета. -1 это как zlib по умолчанию. 0 означает отсутствие сжатия, а 1..9 различные скорости/компромиссы размер 9 быть медленным. Если не установлено, по умолчанию используется core.компрессия. Если это не ставить, по умолчанию -1, значение по умолчанию zlib, которое является "компромиссом по умолчанию между скоростью и сжатием (в настоящее время эквивалентно уровню 6)."

обратите внимание, что изменение степени сжатия не будет автоматически сжимать все существующие объекты. Вы можете принудительно выполнить сжатие, передав параметр-F в git-repack (1).

учитывая достаточную пропускную способность сети, это будет в результате быстрее клонов. не забываем про git-repack -F когда вы решите пример этого!

25

используйте глубину для создания неглубокого клона.

git clone --depth 1 <repository>
22

поняв, что верхним пределом скорости передачи данных является ssh-соединение, которое установлено "вне" git, я провел некоторые эксперименты и обнаружил, что верхний предел использования pcsp (Putty scp) был 3,0 МБ/с, поскольку схема шифрования blowfish была правильно выбрана. Контрольный эксперимент с raw ftp показал, что скорость передачи данных составляет 3,1 Мбит / С, поэтому он показал, что это верхняя граница сети.

Это работает внутри гипервизора VMware, и как процесс, делающий сетевой ввод-вывод, использовал почти 100% cpu, он указал, что узким местом был драйвер сетевой карты Ubuntu. Затем я обнаружил, что, хотя инструменты vmware были установлены, по какой-то причине ядро все еще использовало драйвер vlance (эмулируя сетевую карту 10 MBps с IRQ и всеми) вместо драйвера vmxnet (который говорит непосредственно с гипервизором). Теперь это ожидает изменения окна службы.

другими словами, проблема была не с git, а в основе "аппаратура."

4

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

1