Как часто следует использовать git-gc?

Question

Как часто следует использовать git-gc?

А страница руководства просто говорит:

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

Есть ли какие-нибудь команды, позволяющие подсчитать количество объектов и узнать, пора ли собирать сборщик мусора?

Answer 1

В основном это зависит от того, насколько часто используется репозиторий.Если один пользователь регистрируется один раз в день, а операция ветвления/слияния/и т. д. – раз в неделю, вам, вероятно, не понадобится запускать ее чаще одного раза в год.

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

Однако не помешает запускать его чаще, чем необходимо.

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

Answer 2

Обратите внимание, что недостатком сборки мусора в вашем репозитории является то, что мусор собирается.Как мы все знаем, как пользователи компьютеров, файлы, которые мы сейчас считаем мусором, могут оказаться очень ценными через три дня.Тот факт, что git хранит большую часть своего мусора, несколько раз спасал меня — просматривая все висячие коммиты, я восстановил большую часть работы, которую случайно забанил.

Так что не будьте слишком аккуратными в своих личных клонах.В этом нет особой необходимости.

OTOH, ценность возможности восстановления данных сомнительна для репозиториев, используемых в основном в качестве удаленных, например.место, куда все разработчики отправляют и/или извлекают данные.Там, возможно, было бы разумно часто запускать сборку мусора и переупаковку.

Answer 3

Последние версии git запускают gc автоматически, когда это необходимо, поэтому вам не нужно ничего делать.См. раздел «Параметры» мужик git-gc(1):«Некоторые команды git запускают git gc --auto после выполнения операций, которые могут создать множество незакрепленных объектов».

Answer 4

Если вы используете Git-Gui, это говорит тебе когда вам следует беспокоиться:

This repository currently has approximately 1500 loose objects.

Следующая команда выведет аналогичное число:

$ git count-objects

Кроме, из своего источника, git-gui сам выполнит математические вычисления, фактически посчитав что-то в .git/objects папку и, вероятно, приводит приблизительное представление (я не знаю tcl чтобы правильно это прочитать!).

В любом случае это кажется выдать предупреждение на основе произвольного числа вокруг 300 незакрепленных предметов.

Answer 5

Добавьте это в задание cron, которое запускается каждую ночь (днем?), когда вы спите.

Answer 6

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

Answer 7

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

Видеть зафиксировать 4c4ac4d и зафиксировать 9f673f9 (Нгуен Тхай Нгок Дуй, он же pclouds):

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

---

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

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

Пока зафиксировать 9f673f9 (gc:опция конфигурации для запуска --auto на заднем плане — 8 февраля 2014 г.) помогает уменьшить количество жалоб на «gc --auto' перехватывая терминал, это создает еще один набор проблем.

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

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

Answer 8

Эта цитата взята из;Контроль версий с помощью Git

Git автоматически запускает сбор мусора:

• Если в репозитории слишком много незакрепленных объектов

• Когда происходит отправка в удаленный репозиторий

• После некоторых команд, которые могут привести к появлению большого количества незакрепленных объектов

• Когда срок действия некоторых команд, таких как git reflog, истекает, они явно запрашивают это.

И, наконец, сбор мусора происходит, когда вы явно запросите его с помощью команды GIT GC.Но когда это должно быть?Там нет надежного ответа на этот вопрос, но есть несколько хороших советов и лучших практик.

Вы должны рассмотреть возможность запуска GIT GC вручную в нескольких ситуациях:

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

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

А с другой стороны, когда вы должны опасаться коллекции мусора?

• Если есть потерянные ссылки, которые вы, возможно, захотите восстановить.

• В контексте git rerere, и вам не нужно навсегда сохранять резолюции

• В контексте только тегов и ветвей, достаточных для того, чтобы GIT навсегда сохранил коммит

• В контексте поиска FETCH_HEAD (поиск url-receect через Git Fetch), потому что они сразу же подвергаются сбору мусора

• В контексте только тегов и ветвей, достаточных для того, чтобы GIT навсегда сохранил коммит

• В контексте поиска FETCH_HEAD (поиск url-receect через Git Fetch), потому что они сразу же подвергаются сбору мусора

Answer 9

Я использую, когда делаю большой коммит, особенно когда удаляю больше файлов из репозитория.после этого коммиты выполняются быстрее