Що означає "Автоматичне пакування сховища для досягнення оптимальної продуктивності"?

У мене виникають проблеми з моїм gpo repo. Протягом останніх кількох днів, коли я натискаю на сервер, я отримую таке повідомлення: "Автоматичне пакування сховища для оптимальної продуктивності", і воно, схоже, не відходить і повертає оболонку.

Я також спробував перейти до нової гілки, а потім зробив ребайн для попередньої гілки, а потім зробив, git gcщоб видалити невикористані об’єкти історії, а потім здійснив поштовх, але все-таки це повідомлення з’являється. Будь ласка, дайте мені знати, що відбувається з моїм репо.

Коротка версія: це означає, що вона говорить, і якщо ви просто дозволите це закінчити, все буде добре.

Під час більшості операцій, які потенційно можуть збільшити кількість вільних (розпакованих) об'єктів у сховищі (включаючи натискання), Git викликає git gc --auto. Якщо є достатньо вільних об'єктів (за замовчуванням, принаймні 6700), то вони будуть викликати git repack -d -lїх упаковку. Якщо занадто багато окремих упаковок, вони також перепакують їх в одну.

Пакет - це єдиний файл, стислий дельту, що містить велику кількість об'єктів. Зберігати об’єкти в пакетах більш ефективно, але потрібен час для пакування (стискання) об'єктів, тому Git спочатку створює пухкі об'єкти, потім упакує їх у пакети раз у раз за допомогою автоматичного виклику git gc --auto.

Якщо ви дозволите Git закінчити переукладання, це не повториться на деякий час. Це дійсно може зайняти деякий час, особливо якщо у вас багато великих бінарних об'єктів, але якщо це спрацьовує, то це знак того, що це, ймовірно, різко зменшить кількість дискового простору, зайнятого репо. Якщо ви дійсно не хочете, щоб це сталося, ви можете змінити параметр config gc.auto. Якщо ви збільшите його до чогось набагато більшого, ніж 6700, це буде траплятися рідше, але займе більше часу, коли це станеться. Якщо зменшити його, все одно доведеться виконати поточний перепакування, але згодом це станеться частіше і закінчиться швидше. Якщо встановити його на 0, це вимкне автоматичне перепакування.

Див. man git-gc(Під --auto) та man git-config(під gc.auto) для отримання додаткової інформації.

Хоча Джефроні правдивий, що іноді для автоматичного упаковки просто потрібен час для завершення, якщо повідомлення про автоматичне пакування зберігається протягом декількох днів, як описано в ОП, є хороший шанс, що в очищенні Git відсутні відсутні звисаючі об'єкти, як описано в цьому питанні .

Щоб побачити, чи запускають звисаючі об'єкти постійні повідомлення про автоматичне пакування, спробуйте запустити git fsck. Якщо у вас довгий перелік звисаючих доручень, ви можете їх очистити

git gc --prune=now

Зазвичай мені доводиться запускати це на моїй репо кожних 2-3 місяці, коли повідомлення про автоматичне пакування не зникає після одного потягу.

Щоб відключити один проект:

cd your_project_dir
git config gc.auto 0

Щоб відключити глобально:

git config --global gc.auto 0

Git - це git-repack, який пакує багато об'єктів (= файли, комірки та дерева) в один файл пакету. Git робить це іноді, коли евристика каже, що можна зберегти простір (пакетний файл містить стиснуті дельти об'єкта, тоді як кожен файл у об'єктах / каталозі містить стислий повний вміст файлу)

Сподіваємось, цей git gc --autoкрок зараз (git 2.0.1, 25 червня 2014 р.) Більш ефективний.
Див здійснювати 62aad18 по Nguyễn THAI Нгок Duy ( pclouds)

gc --auto: не фіксуйте посилання на задньому плані

9f673f9 ( gc: параметр config для запуску --auto у фоновому режимі - 2014-02-08, Git 2.0.0) ставить " gc --auto" у фоновий режим, щоб скоротити час очікування користувача.
Частина сміттєзбирального комплексу - це пакети з переробки та обрізка. Вони потребують блокування деяких посилань і можуть перервати інші процеси, намагаючись заблокувати ту саму.

Якщо gc --autoбуде запущено посеред сценарію, gc, утримуючи блокування у фоновому режимі, може зірвати сценарій, що ніколи не могло статися до 9f673f9 .

Продовжуйте працювати pack-refsта " reflog --prune" на передньому плані, щоб зупинити паралельні оновлення оновлень. Решта фонових операцій (переупаковка, підрізання та повторне оновлення) не повинні впливати на запущені процеси git.

А Git 2.22 (Q2 2019) додатково оптимізуютьgit gc .