Я видел git gc --aggressive --prune и git repack -a -d --depth=250 --window=250, рекомендуемые для уменьшения размера ваших локальных .git-папок, где длинная локальная история не нужна.
Из моего чтения кажется, что git-repack является предпочтительным, может ли кто-нибудь прокомментировать это?
Я действительно хочу знать, как определить значения для depth и window. Я использую git для фиксации, push, pull и merge, я понятия не имею, что такое треугольная цепочка или окно объекта.
"Окно объекта" - при переупаковке git сравнивается каждый объект (каждая версия каждого файла, каждый объект дерева каталогов, каждое сообщение фиксации, каждый тег...) против некоторого количества других аналогичных объектов, чтобы найти тот, который создает наименьшую дельта - грубо говоря, самый маленький патч, который может создать этот объект из этого базового объекта.
"Delta chain" - Когда для воссоздания объекта A вам сначала нужно проверить объект B и применить к нему дельта, но для создания B вам нужен объект C, который требует D....
До точки, увеличивая как depth, так и window, вы можете получить меньшие пакеты. Однако есть компромиссы. Для window более высокая настройка означает, что git repack будет сравнивать каждый объект с большим количеством объектов во время его работы, что приведет к (потенциально значительному) увеличению времени работы git repack. Однако, как только пакет сгенерирован, window не влияет на дальнейшие операции (вне других repack s, во всяком случае). depth, с другой стороны, оказывает меньшее влияние на время выполнения самого git repack (хотя оно все еще несколько влияет на него), но чем глубже ваши деревья дельты, тем дольше требуется перестроить старый объект из последовательность базовых объектов, необходимых для создания файла. Это означает, что для таких вещей, как checkout, когда вы ссылаетесь на более старые коммиты, это означает более длительные времена, поэтому оно может существенно повлиять на воспринимаемую эффективность git, если вы много работаете в своей истории. И поскольку git не создает дельта только для старых объектов, вы можете иногда найти последний объект, который медленно извлекается, потому что он имеет несколько уровней вниз по дереву - он не так часто встречается, как со старыми объектами, но он происходит.
Я лично использую window=1024 и depth=256 во всех моих репозиториях, за исключением нескольких клонов очень больших проектов (например, ядро Linux).
Я провел несколько тестов с разными значениями. Это слишком велико, чтобы быть комментарием к ответу twalbergs.
Моя компания имеет базу кода, которая была в svn, mercurial и теперь git. Это 10 лет, с 21 000 коммитов.
До пакета было 3,1 ГБ. После переупаковки оно уменьшилось до следующих значений:
(каждый раз запускать репаку на новый клон в папке 3.1 ГБ).
git repack -a -d --depth=50 --window=10 -f
141.584 MB
git repack -a -d --depth=250 --window=1000 -f
110.484 MB
git repack -a -d --depth=500 --window=1000 -f
110.204 MB
Они заняли около 5, 15 и 30 минут соответственно на моем четырехъядерном процессоре mac.
Update:
Я взял вторую репаку (250,1000) и запустил переупаковку с 500 и 1000, чтобы увидеть, есть ли разница между новым ретранслятором 3.1gb и уже переупакованным повтором 110mb.
git repack -a -d --depth=250 --window=1000 -f
110.484 MB
git repack -a -d --depth=500 --window=1000 -f
110.212 MB
Вердикт: репак 500, 1000 привел к файлу размером 110,2 МБ, независимо от того, был ли он уже упакован или нет.
Update2:
Мне было любопытно, если запуск repack с более низкими значениями на уже упакованном репо вызовет увеличение размера.
git repack -a -d --depth=500 --window=1000 -f
110.204 MB
git repack -a -d --depth=50 --window=10 -f
142.056 MB
Вердикт: репак вызвал размер репо для резервного копирования до ~ 140 МБ от 110 МБ