Як часто слід використовувати 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 сипучих об'єктів.

Опустіть його в роботу з кроном, яка працює щовечора (вдень?), Коли ви спите.

Я використовую git gc після того, як роблю великий замовлення, і маю багато нового об'єкта. це може заощадити місце. Наприклад, якщо ви перевіряєте великий проект SVN за допомогою git-svn і робите git gc, зазвичай ви економите багато місця

Ви можете зробити це без будь-яких перерв, використовуючи нове налаштування (Git 2.0 Q2 2014) gc.autodetach.

Дивіться команду 4c4ac4d і виконувати 9f673f9 ( Nguyễn Thái Ngọc Duy, він же pclouds ):

gc --autoвимагає часу і може блокувати користувача тимчасово (але не менш дратівливо).
Змусьте його працювати у фоновому режимі в системах, які його підтримують.
Єдине, що втрачено при запуску у фоновому режимі - це роздруківки. Але gc outputце насправді не цікаво.
Ви можете зберегти його на передньому плані, змінивши gc.autodetach.

З цього випуску 2.0 з'явилася помилка: git 2.7 (Q4 2015) не забуде повідомлення про помилку .
Див. Комісію 329e6e8 (19 вересня 2015 р.) Від Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Об’єднав Хуніо С Хамано - gitster- у комітеті 076c827 , 15 жовтня 2015 р.)}

gc: збережіть журнал від демонізованого gc --autoта друкуйте його наступного разу

У той час як фіксація 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 rerere, і вам не потрібно зберігати резолюції назавжди

• У контексті достатньо лише тегів та гілок, щоб Git постійно зберігав комісію

• У контексті пошуку FETCH_HEAD (пошук прямих URL-адрес через git fetch), оскільки вони негайно підлягають збору сміття

Я використовую, коли я виконую велику фіксацію, перш за все, коли видаляю більше файлів із сховища.

Не потрібно користуватися git gcдуже часто, оскільки git gc(Збір сміття) запускається автоматично на декількох часто використовуваних командах:

git pull
git merge
git rebase
git commit

Джерело: кращі практики та поширені запитання щодо git gc