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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

Последние версии git запускают gc автоматически при необходимости, поэтому вам не нужно ничего делать. См. Раздел «Параметры» man 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

Вы можете сделать это без перерыва, с новой (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.

---

Начиная с этого выпуска 2.0, была ошибка, хотя: git 2.7 (4 квартал 2015 года) обязательно не потеряет сообщение об ошибке .
См. коммит 329e6e8 (19 сентября 2015 г.) Нгуен Тай Нгок Дуй (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 6

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

Answer 7

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

Answer 8

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

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

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

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

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

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

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

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

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

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

И с другой стороны, когда стоит опасаться за сборку мусора?

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

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

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

• В контексте поиска FETCH_HEAD (прямой URL-адрес через git fetch), потому что они немедленно подлежат сборке мусора

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

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

Answer 9

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