Як пропустити спливаюче вікно "Loose Object" під час запуску "git gui"

Коли я запускаю "git gui", я отримую спливаюче вікно, яке говорить

Зараз у цьому сховищі розміщено приблизно 1500 вільних об'єктів.

Потім пропонується стиснення бази даних. Я робив це раніше, і це зменшує сипучі об'єкти до приблизно 250, але це не пригнічує спливаючі вікна. Повторне стиснення не змінює кількість пухких об'єктів.

Наш поточний робочий процес вимагає значного використання "rebase", оскільки ми переходимо з Perforce, і Perforce все ще є канонічним SCM. Після того, як Git стане канонічним SCM, ми будемо робити регулярні злиття, і проблема сипучих об'єктів повинна бути значно пом'якшена.

У той же час, я дуже хотів би, щоб ця «корисна» спливаюча думка пройшла.

Оскільки ще ніхто не отримав відповіді, я заглянув у код, щоб побачити, як видалити код, який відображається в цьому діалоговому вікні. Я знайшов hint_gcпроцедуру, яка це робить, і місце, де воно викликається. У той же час я помітив, що наприкінці 2011 року було додано параметр конфігурації для відключення діалогу . Цю зміну (частина git-gui 0.16.0) було об'єднано в основну лінію Git 2011-12-14 .

Отже, якщо ви використовуєте Git v1.7.9 або новішої версії, ви можете відключити діалогове вікно попередження за допомогою наступної команди:

git config --global gui.gcwarning false

Якщо ви використовуєте старішу версію, ви можете редагувати /lib/git-core/git-guiта видаляти after 1000 hint_gcрядок, або редагувати /usr/share/git-gui/lib/database.tclта видаляти тіло hint_gcпроцедури. (Ці шляхи до файлів є на Cygwin - в інших середовищах файли можуть знаходитися в інших місцях. Для Windows це c:\Program Files\Git\mingw64\libexec\git-core\git-gui.tcl)

Оновлення: git prune"вирішить" проблему, оскільки вона видалить ті вільні об'єкти
( git gcдзвінки git prune, але лише для вільних об'єктів, старших двох тижнів, за замовчуванням).
Однак, як в коментарях зазначає ОП Майкл Донохуе :

Мені подобається аспект безпеки зберігання сипучих предметів на протязі двох тижнів, якщо я хочу повернутися назад і переглянути деякі старі зміни, тому мені не дуже подобається це рішення.
У мене не виникає проблем з розміром або продуктивністю git, це просто "git gui", який наполягає на тому, щоб я попросив стиснути базу даних, навіть коли стискання бази даних не матиме жодного ефекту.

Оригінальна відповідь:

Проблему " git gc" не видалення всіх пухких об'єктів повідомлялося раніше (наприкінці 2008 р., " " git gc"Більше не видаляє пухкі об'єкти "

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

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

[Приклад: ]Старі гілки зарезервовані за допомогою тегу, такого як next-20081204.
Якщо ви оновлюєте локальну копію linux-nextсховища щодня, ви накопичите велику кількість цих старих тегів філій.
Якщо потім видалити цілу серію з них і запустити git-gc, операція займе досить багато часу, а кількість використаних блоків та вкладів значно зросте.

Вони зникнуть після " git prune", але коли я роблю цю господарську операцію, я часто хотів отримати --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repositoryваріант "git gc".

Отже, у вашому випадку, чи допоможе " git prune" "користь?

(можливо, із застосуванням "зараз" у gc.pruneexpireзмінній конфігурації, необхідній для здійснення вищезазначеної поведінки).

У вас також є (з тієї ж теми):

repack -a -d -l

Зауважте малі літери "а".

git-gcперекликає перезарядку з великого регістру "A", саме це призводить до розпакування недоступних об'єктів. Маленьке «а» - це для людей, які знають, що роблять, і хочуть, щоб git просто кидав недоступні об’єкти.

Коли спливає "Loose Object", я знаю, що настав час запустити збирач сміття git:

git gc

Після цього спливаюче вікно відходить.

Оновлення: (із-за пропозиції TED)

Я витягнув нижчезазначений режим із git/share/git-gui/lib/database.tcl
Ви можете змінити його, щоб відповідати вашим потребам.

proc hint_gc {} {
    set object_limit 8
    if {[is_Windows]} {
        set object_limit 1
    }

    set objects_current [llength [glob \
        -directory [gitdir objects 42] \
        -nocomplain \
        -tails \
        -- \
        *]]

    if {$objects_current >= $object_limit} {
        set objects_current [expr {$objects_current * 256}]
        set object_limit    [expr {$object_limit    * 256}]
        if {[ask_popup \
            [mc "This repository currently has approximately %i loose objects.

To maintain optimal performance it is strongly recommended that you compress the database when more than %i loose objects exist.

Compress the database now?" $objects_current $object_limit]] eq yes} {
            do_gc
        }
    }
}

Хмммм .... Я не бачу аргументу командного рядка для цього в документах .

Я припускаю, що ви завжди можете зняти його джерело, вийняти код для діалогу та відновити його.