Нужно ли мне запускать git gc на голом репо?

Question

man git-gc у меня нет очевидного ответа, и мне тоже не повезло с Google (хотя, возможно, я просто использовал неправильные условия поиска).

Я понимаю, что вы должны время от времени бежать git gc в локальном хранилище, чтобы, среди прочего, обрезать висячие объекты и сжимать историю - но подвержен ли общий голый хранилище этим же проблемам?

Если это имеет значение, наш рабочий процесс состоит из нескольких разработчиков, которые извлекают данные из общего сетевого диска и переносят его в пустой репозиторий. "Центральный" репозиторий был создан с git init --bare --shared,

Answer 1

Как Cascabel прокомментировал ответ Дэна, git gc должен вызываться автоматически, вызывается при "обычном" использовании пустого хранилища.

Я только что побежал git gc --aggressive в двух открытых общих хранилищах, которые активно использовались; один с примерно 38 коммитами за последние 3-4 недели, а другой с примерно 488 коммитами за примерно 3 месяца. Никто не запускал вручную git gc в любом хранилище.

Меньший репозиторий

$ git count-objects
333 objects, 595 kilobytes

$ git count-objects -v
count: 333
size: 595
in-pack: 0
packs: 0
size-pack: 0
prune-packable: 0
garbage: 0

$ git gc --aggressive
Counting objects: 325, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (325/325), done.
Total 325 (delta 209), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.

$ git count-objects -v
count: 8
size: 6
in-pack: 325
packs: 1
size-pack: 324
prune-packable: 0
garbage: 0

$ git count-objects
8 objects, 6 kilobytes

Большой репозиторий

$ git count-objects
4315 objects, 11483 kilobytes

$ git count-objects -v
count: 4315
size: 11483
in-pack: 9778
packs: 20
size-pack: 15726
prune-packable: 1395
garbage: 0

$ git gc --aggressive
Counting objects: 8548, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8468/8468), done.
Writing objects: 100% (8548/8548), done.
Total 8548 (delta 7007), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.

$ git count-objects -v
count: 0
size: 0
in-pack: 8548
packs: 1
size-pack: 8937
prune-packable: 0
garbage: 0

$ git count-objects
0 objects, 0 kilobytes

Я хотел бы подумать об этом, прежде чем я gc редактировал эти два репозитория, но я должен был бежать git gc без --aggressive возможность увидеть разницу. К счастью, у меня осталось активное хранилище среднего размера (164 коммитов за почти 2 месяца).

$ git count-objects -v
count: 1279
size: 1574
in-pack: 2078
packs: 6
size-pack: 2080
prune-packable: 607
garbage: 0

$ git gc
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1073/1073), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1210), reused 1050 (delta 669)
Removing duplicate objects: 100% (256/256), done.

$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1092
prune-packable: 0
garbage: 0

$ git gc --aggressive
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1742/1742), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1249), reused 0 (delta 0)

$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1058
prune-packable: 0
garbage: 0

Бег git gc явно сделал большую вмятину в count-objects хотя мы регулярно push и fetch из этого хранилища. Но после прочтения руководства для git config Я заметил, что предел свободного объекта по умолчанию - 6700, которого мы, очевидно, еще не достигли.

Таким образом, похоже, что вывод нет, вам не нужно бежать git gc вручную на голом репо; ^* но с настройкой по умолчанию для gc.auto, может пройти много времени, прежде чем сборка мусора произойдет автоматически.

---

_{^* Как правило, вам не нужно запускать} git gc _{, Но иногда вы можете быть ограничены в космосе, и вы должны бежать} git gc _{вручную или установить} gc.auto _{к более низкому значению. Мой вопрос был просто любопытным.}

Answer 2

От git-gc справочная страница:

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

Акцент мой. Голые репозитории тоже репозитории!

Дальнейшее объяснение: одна из хозяйственных задач, которая git-gc выполняет упаковку и переупаковку сыпучих предметов. Даже если в вашем голом хранилище никогда не будет висящих объектов, со временем вы будете накапливать множество незакрепленных объектов. Эти незакрепленные предметы должны периодически упаковываться для эффективности. Точно так же, если накапливается большое количество упаковок, они должны периодически переупаковываться в более крупные (меньшие) упаковки.

Answer 3

Вопрос с git gc --auto в том, что это может быть блокировка.

Но с новой (Git 2.0 Q2 2014) настройкой gc.autodetach Теперь вы можете сделать это без перерыва:

Смотрите коммит 4c4ac4d и коммит 9f673f9 ( Nguy Thn Thái Ngọc Duy, он же pclouds):

gc --auto занимает время и может временно блокировать пользователя (но не менее раздражающе).
Заставьте его работать в фоновом режиме на системах, которые его поддерживают.
Единственное, что теряется при работе в фоновом режиме - это распечатки. Но gc output не очень интересно.
Вы можете сохранить его на переднем плане, изменив gc.autodetach,

---

Примечание: только git 2.7 (4 квартал 2015 года) не потеряет сообщение об ошибке.
См. Коммит 329e6e8 (19 сентября 2015 г.) Нгуен Тхай Нгук Дуй ( pclouds )
^{(Объединено Юнио С Хамано -} gitster ^{- в коммите 076c827 от 15 октября 2015 г.)}

gc: сохранить журнал из демонизированного gc --auto и распечатать в следующий раз

Пока совершаю 9f673f9 (gc: опция конфигурации для запуска --auto в фоновом режиме - 2014-02-08) помогает уменьшить некоторые жалобы на gc --auto "Захватив терминал", он создает еще один набор проблем.

Последнее в этом наборе, в результате демонизации, stderr закрыто и все предупреждения потеряны. Это предупреждение в конце cmd_gc() особенно важно, потому что он говорит пользователю, как избежать " gc --auto "работает неоднократно.
Поскольку stderr закрыт, пользователь не знает, естественно, что он жалуется gc --auto тратить процессор.

Daemonized gc теперь сохраняет stderr в $GIT_DIR/gc.log ,
Следующий gc --auto не будет работать и gc.log распечатан, пока пользователь не удалит gc.log,

Answer 4

Некоторые операции выполняются git gc --auto автоматически, поэтому никогда не должно быть необходимости запускать git gcGit должен сам позаботиться об этом.

Вопреки тому, что сказал bwawok, на самом деле есть (или может быть) разница между вашим локальным репо и тем голым: какие операции вы выполняете с ним. Например, висячие объекты могут быть созданы путем перебазирования, но может случиться так, что вы никогда не перебазируете голое репо, поэтому, возможно, вам никогда не придется их удалять (потому что их никогда не будет). И, таким образом, вам не нужно использовать git gc это часто. Но опять же, как я уже сказал, git должен позаботиться об этом автоматически.

Answer 5

Я не знаю на 100% о логике gc.. но рассуждать об этом:

git gc удаляет лишнюю ненужную историю, сжимает лишнюю историю и т. д. Он ничего не делает с вашими локальными копиями файлов.

Единственное различие между обычным и обычным репо - это наличие локальных копий файлов.

Так что, я думаю, что понятно, что ДА, вы должны запустить git gc на голом репо.

Я никогда не запускал его лично, но мой репо довольно маленький и все еще быстрый.