Должен ли я когда-либо запускать git gc на голой репо?

Ответ 1

Как Jefromi прокомментировал ответ Dan, 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 транзакции в течение почти двух месяцев).

$ 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 to и fetch из этого репозитория. Но, прочитав manpage для git config, я заметил, что ограничение по умолчанию для объектных объектов - 6700, чего мы, по-видимому, еще не достигли.

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

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

Ответ 2

На странице git-gc man:

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

Акцент мой. Голые репозитории также являются хранилищами!

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

Ответ 3

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

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

Ответ 4

Проблема с git gc --auto заключается в том, что она может блокироваться.

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

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

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

Примечание: только git 2.7 (Q4 2015) убедитесь, что не потерял сообщение об ошибке.
См. commit 329e6e8 (19 сентября 2015 г.) Nguyễn Thái Ngọc Duy (pclouds).
^{(слияние Юнио С Хамано - gitster - в совершить 076c827, 15 октября 2015 г.)}

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

Пока commit 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.

Ответ 5

Я не знаю 100% о логике gc.., но для этого:

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

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

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

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