Как часто вы должны использовать git-gc?

Как часто вы должны использовать git-gc?

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

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

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

Это зависит главным образом от того, сколько используется хранилище. Когда один пользователь проверяет один раз в день, а разветвление / слияние / и т. Д. Раз в неделю, вам, вероятно, не нужно запускать его чаще, чем раз в год.

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

Впрочем, запускать его чаще, чем нужно, не помешает.

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

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

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

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

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

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

This repository currently has approximately 1500 loose objects.

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

$ git count-objects

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

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

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

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

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

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

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

Начиная с этого релиза 2.0, была ошибка: git 2.7 (4 квартал 2015 года) не потеряет сообщение об ошибке .
См. Коммит 329e6e8 (19 сентября 2015 г.) Нгуена Тхаи Нгука Дуй ( pclouds) .
^{(Слиты Junio C Hamano - gitster- в фиксации 076c827 , 15 окт 2015)}

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

Хотя commit 9f673f9 ( gc: опция config для запуска --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 .

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

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

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

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

• После некоторых команд, которые могут ввести много свободных объектов

• Когда срок действия некоторых команд, таких как git reflog, истекает

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

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

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

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

И с другой стороны, когда вы должны быть осторожны с сборкой мусора?

• Если есть осиротевшие рефери, которых вы можете восстановить

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

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

• В контексте поиска FETCH_HEAD (прямой URL-адрес с помощью git fetch), поскольку они немедленно подвергаются сборке мусора.

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

Вам не нужно использовать git gcочень часто, потому что git gc(сборка мусора) запускается автоматически по нескольким часто используемым командам:

git pull
git merge
git rebase
git commit

Источник: лучшие практики git gc и часто задаваемые вопросы