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

Question

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

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

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

Answer 1

Как прокомментировал Джефроми Ответ Дэна , 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 теперь вы можете делать это без перерыва:

См. commit 4c4ac4d и commit 9f673f9 ( Nguy Thn Thái Ngọc Duy, aka pclouds ):

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

---

Примечание: только git 2.7 (четвертый квартал 2015 года) будет не потерять сообщение об ошибке .
См. коммит 329e6e8 (19 сентября 2015 г.) от Nguy Thn Thái Ngọc Duy (pclouds) .
^{(Объединено с Junio ​​C Hamano - gitster - in commit 076c827 , 15 октября 2015 г.)}

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

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

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

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

Answer 4

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

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

Answer 5

Я не знаю на 100% о логике gc .. но чтобы это объяснить:

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

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

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

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