Как я могу узнать, что `git gc --auto` что-то сделал?

Question

Как я могу узнать, что `git gc --auto` что-то сделал?

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

3

git

Источник

user2140271 31 июл '17 в 22:31

1 ответ

Другие вопросы по тегам git

user6309 26 сен '20 в 14:39 2020-09-26 14:39 · Answer 1 · 2020-09-26 14:39

Обновление от сентября 2020 года: вам не нужно будет только запускать git gc --auto как часть вашего сценария автоматического сохранения.

Старый "gc"теперь может быть заменен новым git maintainance run --auto.
И он может отображать то, что делает.

С Git 2.29 (4 квартал 2020 г.), A " git gc"^{(Человек)}"s старший брат был введен, чтобы заботиться о более репозитария задач обслуживания, не ограничивается очисткой базы данных объекта.

См. Фиксацию 25914c4, фиксацию 4ddc79b, фиксацию 916d062, фиксацию 65d655b, фиксацию d7514f6, фиксацию 090511b, фиксацию 663b2b1, фиксацию 3103e98, фиксацию a95ce12, фиксацию 3ddaad0, фиксацию 2057d75 (17 сентября 2020 г.) Деррик Столи (derrickstolee).
^{(Слияние Junio C Hamano -
gitster- в коммите 48794ac, 25 сентября 2020 г.)}

maintenance: создать базовую программу обслуживания
^{Помощник: Джонатан Нидер.}
^{Подпись: Деррик Столи.}

Встроенная функция "gc" - это наша текущая точка входа для автоматического обслуживания репозитория. Этот инструмент выполняет множество операций, например:
перепаковка репозитория,
ссылки на упаковку и
перезапись файла фиксации графа.
Название подразумевает, что он выполняет "сборку мусора", что означает несколько разных вещей, и некоторые пользователи могут не захотеть использовать эту операцию, которая перезаписывает всю базу данных объектов.
Создать новый 'maintenance'встроенный, который станет командой более общего назначения.
Для начала он будет поддерживать только 'run', но позже будет расширена добавлением подкоманд для планирования обслуживания в фоновом режиме.
Пока что 'maintenance'builtin - тонкая прокладка над'gc'встроенный.
Фактически, единственный вариант - это '--auto'переключатель, который передается непосредственно'gc'встроенный.
Текущее изменение изолировано от этой простой операции, чтобы предотвратить потерю более интересной логики во всем шаблоне добавления новой встроенной функции.
Использовать существующие builtin/gc.c файл, потому что мы хотим разделить код между двумя встроенными командами.
Возможно, у нас будет 'maintenance' заменить 'gc'построен полностью в какой-то момент, оставив'git gc^(man)'как псевдоним для некоторых конкретных аргументов'git maintenance run'.
Создать новый test_subcommandпомощник, который позволяет нам проверить, была ли запущена определенная подкоманда. Это требует хранения GIT_TRACE2_EVENTрегистрирует в файле.
Доступен режим отрицания, который будет использоваться в последующих тестах.

(Эта последняя часть - один из способов узнать новый git maintainance run --auto что-то делает)

git maintenanceтеперь включает в свою справочную страницу:

git-обслуживание (1)
ИМЯ
git-maintenance - Запускать задачи для оптимизации данных репозитория Git
ОБЗОР
[verse]
'git maintenance' run [<options>]
ОПИСАНИЕ
Выполняйте задачи для оптимизации данных репозитория Git, ускорения выполнения других команд Git и сокращения требований к хранилищу для репозитория.
Команды Git, которые добавляют данные репозитория, например git add или же git fetch, оптимизированы для быстрого взаимодействия с пользователем. Этим командам не требуется времени для оптимизации данных Git, поскольку такая оптимизация масштабируется с учетом полного размера репозитория, а каждая из этих пользовательских команд выполняет относительно небольшое действие.
В git maintenance Команда обеспечивает гибкость при оптимизации репозитория Git.
ПОДСКАЗКИ
run
Выполните одну или несколько задач обслуживания.
ЗАДАНИЯ
gc
Удалите ненужные файлы и оптимизируйте локальный репозиторий. "GC" означает "сборку мусора", но эта задача выполняет множество более мелких задач. Эта задача может быть дорогостоящей для больших репозиториев, поскольку она объединяет все объекты Git в один файл-пакет. В некоторых ситуациях это также может мешать работе, так как удаляет устаревшие данные. Видеть git gc для получения дополнительных сведений о сборке мусора в Git.
ПАРАМЕТРЫ
--auto
В сочетании с runподкоманда, запускайте задачи обслуживания только при достижении определенных пороговых значений. Например, gc задача запускается, когда количество незакрепленных объектов превышает количество, хранящееся в gc.auto config, или когда количество pack-файлов превышает gc.autoPackLimit настройка конфигурации.

maintenance: заменить run_auto_gc()
^{Подписано: Деррик Столи}

В run_auto_gc() используется в нескольких местах для запуска проверки обслуживания репо после некоторых команд Git, таких как 'git commit'^{(мужчина)} или'git fetch'^{(мужчина)}.
Чтобы разрешить дополнительную настройку этого действия по обслуживанию, замените 'git gc --auto [--quiet]^{(мужчина)}'позвони с одним к'git maintenance run --auto [--quiet]^{(мужчина)}'.
Поскольку мы расширяем встроенное обслуживание другими шагами, пользователи смогут выбирать различные действия по обслуживанию.
Переименовать run_auto_gc() к run_auto_maintenance()чтобы было понятнее, что происходит в этом вызове, и показать всех вызывающих в текущем diff. Перепишите метод, чтобы использовать структуру child_process чтобы немного упростить вызовы.
Поскольку 'git fetch'^{(человек)} уже позволяет отключить'git gc --auto'^(man)subprocess, добавьте эквивалентную опцию с другим именем, чтобы лучше описывать новое поведение:'--[no-]maintenance'.

fetch-optionsтеперь включает в свою справочную страницу:

Бежать git maintenance run --autoв конце, чтобы при необходимости выполнить автоматическое обслуживание репозитория. (--[no-]auto-gcявляется синонимом.)
По умолчанию включено.

git cloneтеперь включает в свою справочную страницу:

который автоматически вызывает git maintenance run --auto. (Видеть git maintenance.)

Кроме того, ваш сценарий сохранения сможет сделать git maintenance делать больше, чем git gcкогда-либо мог, благодаря задачам.

maintenance: add --task option
^{Подписано: Деррик Столи}

Пользователь может захотеть запускать только определенные задачи обслуживания в определенном порядке.
Добавить --task=<task>опция, которая позволяет пользователю указать упорядоченный список задач для запуска. Однако их нельзя запускать несколько раз.
Вот где наш массив maintenance_taskуказатели становится критичным. Мы можем отсортировать массив указателей на основе порядка задач, но мы не хотим перемещать сами данные структуры, чтобы сохранить ссылки на хэш-карту. Мы используем хэш-карту для сопоставления аргументов --task= с данными структуры задачи.
Имейте в виду, что 'enabled'член maintenance_task struct - это заполнитель для будущего 'maintenance.<task>.enabled'опция конфигурации. Таким образом, мы используем 'enabled'член, чтобы указать, какие задачи запускаются, когда пользователь не указывает никаких --task=<task>аргументы.
'enabled'член следует игнорировать, если --task=<task> появляется.

git maintenanceтеперь включает в свою справочную страницу:

Выполните одну или несколько задач обслуживания. Если один или несколько --task=<task>указаны параметры, затем эти задачи запускаются в указанном порядке. В противном случае только gc задача запущена.

git maintenanceтеперь включает в свою справочную страницу:

--task=<task>
Если этот параметр указан один или несколько раз, то запускаются только указанные задачи в указанном порядке. См. Список принятых в разделе "ЗАДАЧИ" <task> значения.

И:

maintenance: создать конфигурацию обслуживания..enabled
^{Подписано: Деррик Столи}

В настоящее время нормальный запуск " git maintenance run"^{( человек)} будет запускать только 'gc'задача, так как она единственная включенная.
Это в основном по причинам обратной совместимости, поскольку " git maintenance run --auto"^{( man)} команды заменили предыдущие"git gc --auto"команды после некоторых процессов Git.
Пользователи могли вручную запускать определенные задачи обслуживания, позвонив по номеру "git maintenance run --task=<task>"прямо".
Разрешить пользователям настраивать, какие шаги запускаются автоматически, с помощью config. 'maintenance.<task>.enabled'затем можно включить эти другие задачи (или отключить'gcзадача).

git configтеперь включает в свою справочную страницу:

maintenance.<task>.enabled
Этот логический параметр конфигурации определяет, будет ли задача обслуживания с именем <task> запускается, когда нет --task опция указывается дляgit maintenance run. Эти значения конфигурации игнорируются, если--taskвариант существует.
По умолчанию только maintenance.gc.enabled правда.

git maintenanceтеперь включает в свою справочную страницу:

Выполните одну или несколько задач обслуживания. Если один или несколько --taskуказаны параметры, затем эти задачи выполняются в указанном порядке. В противном случае определяются задачи, по которым maintenance.<task>.enabledпараметры конфигурации верны.
По умолчанию только maintenance.gc.enabled правда.

git maintenanceтеперь также включает в свою справочную страницу:

Если нет --task=<task>указываются аргументы, то только задачи сmaintenance.<task>.enabled настроен как true считаются.

Еще один способ узнать, есть ли новый git maintenance run в настоящее время что-либо делает, чтобы проверить блокировку (.git/maintenance.lock файл):

maintenance: заблокировать каталог объектов
^{Подписано: Деррик Столи}

Выполнение обслуживания репозитория Git включает запись данных в .gitкаталог, что небезопасно делать с несколькими авторами, пытающимися выполнить одну и ту же операцию.
Убедитесь, что только один git maintenance'^(man) процесс выполняется одновременно, удерживая файловую блокировку.
Просто наличие .git/maintenance.lockфайл предотвратит дальнейшее обслуживание. Эта блокировка никогда не фиксируется, поскольку не представляет значимых данных. Вместо этого это всего лишь заполнитель.
Если файл блокировки уже существует, попытки обслуживания не выполняются. Это станет очень важным позже, когда мы реализуем 'prefetch'задача, поскольку это наша остановка от создания рекурсивного цикла процесса между'git fetch'^{(мужчина)} ' и ' git maintenance run --auto^{(мужчина)}.

Вы также можете проверить, есть ли git gc/git maintenance будет иметь что - либо сделать.

С Git 2.29 (4 квартал 2020 г.), A " git gc"^{(Человек)} "s старший брат был введен, чтобы заботиться о более репозитария задач технического обслуживания, не ограничивается очисткой базы данных объекта.

См. Фиксацию 25914c4, фиксацию 4ddc79b, фиксацию 916d062, фиксацию 65d655b, фиксацию d7514f6, фиксацию 090511b, фиксацию 663b2b1, фиксацию 3103e98, фиксацию a95ce12, фиксацию 3ddaad0, фиксацию 2057d75 (17 сентября 2020 г.) Деррик Столи (derrickstolee).
^{(Слияние Junio C Hamano -
gitster- в коммите 48794ac, 25 сентября 2020 г.)}

maintenance: используйте указатели для проверки --auto
^{Подписано: Деррик Столи}

'git maintenance run^(man) 'команда имеет параметр'--auto'. Это используется другими командами Git, такими как 'git commit^{(мужчина)} 'или'git fetch^(man) ', чтобы проверить, следует ли запускать обслуживание после добавления данных в репозиторий.
Раньше это --auto опция использовалась только для добавления аргумента в 'git gc'^{(человек)} команда как часть'gc'задача.
Мы будем расширять другие задачи, чтобы проверить, должны ли они работать как часть --auto флаг, когда они включены в config.
Сначала обновите задачу "gc", чтобы выполнить автоматическую проверку в процессе обслуживания.
Это предотвращает запуск лишнего 'git gc --auto'^(man) команда, когда она не нужна.
Он также показывает модель для других задач.
Во-вторых, используйте 'auto_condition'указатель на функцию как сигнал о том, разрешаем ли мы задачу обслуживания в'--auto'.
Например, мы не хотим включать задачу "выборка" в "--auto', поэтому указатель на функцию останется NULL.
Мы продолжаем передавать параметр '--auto' в 'git gc'^{(человек)} команда, когда это необходимо, из-за gc.autoDetachПараметр config изменяет поведение.
Вероятно, мы захотим поглотить демонизирующее поведение, подразумеваемое gc.autoDetach как maintenance.autoDetach вариант конфигурации.

Чтобы проиллюстрировать, что git maintenance сделаю это git gc не будет:

maintenance: добавить задачу фиксации графа
^{Подписано: Деррик Столи}

Первое новое задание в 'git maintenance^{(человек)} 'встроенный в'commit-graph'задача.
Это обновляет файл графика фиксации постепенно с помощью команды
git commit-graph write --reachable --split  
Написав инкрементный файл графика фиксации, используя "--split"вариант минимизировать сбои от этой операции.
По умолчанию слои объединяются до тех пор, пока размер нового "верхнего" слоя не станет меньше половины размера нижележащего. Это обеспечивает быструю запись в большинстве случаев, при этом более длительная запись выполняется по степенному закону.
Что наиболее важно, параллельные процессы Git просматривают файл цепочки фиксации-графа только в течение очень короткого промежутка времени, поэтому они, скорее всего, не будут удерживать дескриптор файла, когда мы попытаемся его заменить. (Это имеет значение только в Windows.)
Если параллельный процесс читает старый файл коммит-граф-цепочки, но наша работа истекает некоторые из .graphфайлы до того, как их можно будет прочитать, то эти процессы увидят предупреждающее сообщение (но не потерпят неудачу). Этого можно было бы избежать с помощью будущего обновления, чтобы использовать --expire-time аргумент при написании коммит-графа.

git maintenanceтеперь включает в свою справочную страницу:

commit-graph
В commit-graph работа обновляет commit-graph файлы постепенно, затем проверяет правильность записанных данных.
Добавочную запись можно безопасно запускать вместе с параллельными процессами Git, поскольку срок ее действия не истекает. .graph файлы, которые были в предыдущемcommit-graph-chainфайл. Они будут удалены при более позднем запуске из-за задержки истечения срока действия.

И:

maintenance: добавить автоматическое условие для commit-graph задача
^{Подписано: Деррик Столи}

Вместо того, чтобы писать новый commit-graph в каждом 'git maintenance run --auto'^{(человек)} процесс (когда maintenance.commit-graph.enabled настроен как true), писать только тогда, когда "достаточно" коммитов не в commit-graph файл.
Это количество контролируется maintenance.commit-graph.auto вариант конфигурации.
Чтобы вычислить количество, используйте поиск в глубину, начиная с каждой ссылки и оставляя маркеры с помощью SEENфлаг.
Если это количество достигает предела, прервитесь раньше и запустите задачу.
В противном случае эта операция очистит каждую ссылку и проанализирует фиксацию, на которую она указывает. Если это все в commit-graph, то обычно это очень быстрая операция.
Пользователи с большим количеством ссылок могут почувствовать замедление и, следовательно, могут рассмотреть возможность обновления своего лимита, чтобы он был очень маленьким. Отрицательное значение заставит шаг запускаться каждый раз.

git configтеперь включает в свою справочную страницу:

maintenance.commit-graph.auto
Этот целочисленный параметр конфигурации определяет, как часто commit-graph задача должна выполняться как часть git maintenance run --auto.
Если ноль, то commit-graph задача не будет работать с --auto вариант.
Отрицательное значение заставит задачу запускаться каждый раз.
В противном случае положительное значение означает, что команда должна выполняться, когда количество достижимых коммитов, которых нет в файле графа фиксации, не меньше значения maintenance.commit-graph.auto.
Значение по умолчанию - 100.

В Git 2.30 (первый квартал 2021 г.) расширение тестового покрытия commit-graph задача " git maintenance"^{(человек) по} мере необходимости привел к обнаружению и исправлению ошибки.

См. Фиксацию d334107 (12 октября 2020 г.) и фиксацию 8f80180 (8 октября 2020 г.) Деррика Столи (derrickstolee).
^{(Слияние Junio C Hamano -
gitster- в коммите 0be2d65, 02 ноя 2020)}

maintenance: проверить автоматическое состояние графика фиксации
^{Подписано: Деррик Столи}

Автоматическое состояние для commit-graph Обход задачи обслуживания - рефери, ищущие коммиты, которых нет в commit-graphфайл.
Это было добавлено в 4ddc79b2 ("maintenance: добавить автоматическое условие для задачи фиксации графа ", 2020-09-17, Git v2.29.0-rc0 - слияние указано в пакете № 17), но не было протестировано.
Первоначальная цель этого изменения заключалась в том, чтобы продемонстрировать правильную работу функции путем добавления тестов. Однако произошла ошибка с разницей в одну, из-за которой основные тесты maintenance.commit-graph.auto=1 потерпеть неудачу, когда он должен работать.
Тонкость заключается в том, что если подсказки нет в commit-graph, то мы не добавляли это к общему количеству. В тесте мы видим, что мы добавили только одну фиксацию с момента нашей последней записи графа фиксации, поэтому автоматическое условие говорит, что делать нечего.
Исправить просто: добавьте чек для commit-graph положение, чтобы увидеть, что наконечник не в commit-graphфайл перед началом прогулки. Поскольку это происходит до добавления в стек DFS, нам не нужно очищать наш (в настоящее время пустой) список фиксации.
Это добавляет дополнительную сложность для теста, потому что мы также хотим убедиться, что прогулка по родителям действительно помогает. Это означает, что нам нужно добавить как минимум два коммита подряд, не записывая commit-graph. Однако нам также необходимо убедиться, что никакие дополнительные ссылки не указывают на середину этого списка, иначе for_each_ref() в should_write_commit_graph()могут посещать эти коммиты в качестве подсказок, вместо того, чтобы делать обход DFS. Следовательно, последние два коммита добавляются с помощью " git commit"^{( мужчина)} вместо "test_commit".

user6309 01 ноя '20 в 03:45 2020-11-01 03:45 · Answer 2 · 2020-11-01 03:45

С Git 2.30 (первый квартал 2021 г.) " git maintenance" ^{( мужчина)}, расширенный старший брат" git gc" ^{( человек),} представленный в предыдущем ответе, продолжает развиваться.

Это точнее, чем git gc а параметры, представленные в 2.30, позволяют узнать, когда он что-то сделал, как указано в OP.

См. Commit e841a79, commit a13e3d0, commit 52fe41f, commit efdd2f0, commit 18e449f, commit 3e220e6, commit 252cfb7, commit 28cb5e6 (25 сентября 2020 г.) Деррик Столи (derrickstolee).
^{(Слияние Junio C Hamano -
gitster- в коммите 52b8c8c, 27 октября 2020 г.)}

maintenance: добавить задачу инкрементальной переупаковки
^{Подписано: Деррик Столи}

Предыдущее изменение очищало незакрепленные объекты с помощью "свободных объектов", которые можно безопасно запускать в фоновом режиме. Добавьте аналогичное задание, которое выполняет аналогичную очистку для файлов пакета.
Одна проблема с запуском ' git repack^{( man)}'заключается в том, что он предназначен для переупаковки всех упакованных файлов в один упакованный файл. Хотя это наиболее экономичный способ хранения данных объекта, он неэффективен по времени или памяти. Это становится чрезвычайно важным, если репо настолько велико, что пользователь изо всех сил пытается сохранить две копии пакета на своем диске.
Вместо этого выполните "инкрементную" переупаковку, собрав несколько небольших файлов упаковки в новый файл упаковки. Многопакетный индекс облегчает этот процесс с тех пор " git multi-pack-index expire^{( man)}'был добавлен в 19575c7 (" multi-pack-index: реализовать подкоманду "expire" ", 2019-06-10, Git v2.23.0-rc0 - слияние указано в пакете №6) и git multi-pack-index repack^{( man)}'был добавлен в ce1e4a1 (" midx: воплощать в жизнь midx_repack()", 2019-06-10, Git v2.23.0-rc0 - слияние указано в пакете №6).
Задача "инкрементальной переупаковки" выполняет следующие шаги:

' git multi-pack-index write^{( man)}'создает файл индекса нескольких пакетов, если он не существует, и в противном случае обновляет индекс нескольких пакетов, добавляя любые новые файлы пакетов, появившиеся с момента последней записи. Это особенно актуально для задания фоновой выборки.
Когда multi-pack-index видит две копии одного и того же объекта, он сохраняет данные смещения в более новом pack-файле. Это означает, что некоторые старые упакованные файлы могут стать "не имеющими ссылки", что я буду использовать для обозначения "пакетного файла, который находится в списке пакетных файлов индекса multi-pack, но ни один из объектов в multi-pack- index ссылается на место внутри этого pack-файла ".

' git multi-pack-index expire^{( man)}'удаляет все файлы пакетов, на которые нет ссылок, и обновляет индекс нескольких пакетов, чтобы удалить эти файлы пакетов из списка. Это безопасно, поскольку параллельные процессы Git будут видеть multi-pack-index и не открывать эти пакеты при поиске содержимого объекта. (Подобно заданию "свободные объекты", есть некоторые команды Git, которые открывают файлы пакетов независимо от индекса нескольких пакетов, но они используются редко. Кроме того, пользователь, который сам выбирает использование фоновых операций, скорее всего, воздержитесь от использования этих команд.)

' git multi-pack-index repack --bacth-size=<size>^{( мужчина)}'собирает набор файлов пакетов, перечисленных в индексе нескольких пакетов, и создает новый файл пакетов, содержащий объекты, смещения которых перечислены в индексе нескольких пакетов, которые должны находиться в этих объектах. Набор файлов пакетов выбирается жадно путем сортировки файлов пакетов по времени изменения и добавления пакетного файла в набор, если его "ожидаемый размер" меньше, чем размер пакета, до тех пор, пока не будет получен общий ожидаемый размер выбранных пакетных файлов. как минимум размер партии. "Ожидаемый размер" рассчитывается путем деления размера пакетного файла на количество объектов в пакетном файле и умножения его на количество объектов из индекса нескольких пакетов со смещением в этом пакетном файле. Ожидаемый размер приблизительно соответствует тому, сколько данных из этого пакетного файла повлияет на итоговый размер пакетного файла.Предполагается, что размер результирующего pack-файла будет близок к предоставленному размеру пакета.
При следующем запуске задачи инкрементной переупаковки эти переупакованные файлы пакетов будут удалены на этапе истечения срока действия.
В этой версии размер пакета установлен на "0", что игнорирует ограничения размера при выборе файлов пакета. Вместо этого он выбирает все упакованные файлы и переупаковывает все упакованные объекты в один упакованный файл. Это будет обновлено при следующем изменении, но для этого потребуется выполнить некоторые вычисления, которые лучше выделить в отдельное изменение.

Эти шаги основаны на аналогичном шаге фонового обслуживания в Scalar (и VFS для Git). Это было невероятно эффективно для пользователей репозитория ОС Windows. После использования одной и той же VFS для репозитория Git в течение более года у некоторых пользователей были тысячи файлов пакетов, которые в сумме составляли до 250 ГБ данных. Мы заметили, что некоторые пользователи работают с ограничениями дескриптора открытого файла (отчасти из-за ошибки в multi-pack-index, исправленной af96fe3 (" midx: добавить пакеты в packed_gitсвязанный список ", 2019-04-29, Git v2.22.0-rc1 - объединить).
Эти pack-файлы были в основном небольшими, так как они содержали коммиты и деревья, которые были отправлены в источник за определенный час. Протокол GVFS включает этап предварительной выборки, который запрашивает предварительно вычисленные файлы пакетов, содержащие коммиты и деревья по меткам времени. Эти pack-файлы были сгруппированы в "ежедневные" pack-файлы один раз в день на срок до 30 дней. Если пользователь не запрашивал пакеты предварительной выборки более 30 дней, то он получит всю историю коммитов и деревьев в новом большом пак-файле. Это привело к появлению большого количества pack-файлов с плохим дельта-сжатием.
Выполняя этот этап обслуживания пакетных файлов один раз в день, эти репозитории с тысячами пакетов размером более 200 ГБ упали до десятков файлов пакетов размером 30–50 ГБ. Все это было сделано без удаления объектов из системы и с использованием постоянного размера пакета в два гигабайта. После того, как была сделана работа по уменьшению упакованных файлов до небольших размеров, размер пакета в два гигабайта означает, что не каждый запуск запускает операцию переупаковки, поэтому следующий запуск не приведет к истечению срока действия пакетного файла. Это позволило сохранить эти репозитории в "чистом" состоянии.

git maintenanceтеперь включает в свою справочную страницу:

incremental-repack
В incremental-repack задание переупаковывает каталог объектов с помощью multi-pack-indexхарактерная черта. Чтобы предотвратить условия гонки с одновременными командами Git, следует двухэтапный процесс. Во-первых, он вызывает git multi-pack-index expire удалить pack-файлы, на которые не ссылается multi-pack-indexфайл. Во-вторых, он вызывает git multi-pack-index repack выбрать несколько маленьких pack-файлов и перепаковать их в более крупный, а затем обновить multi-pack-indexзаписи, которые относятся к маленьким пакетным файлам для ссылки на новый пакетный файл. Это подготавливает эти небольшие файлы пакетов к удалению при следующем запуске git multi-pack-index expire. Выбор маленьких пакетных файлов таков, что ожидаемый размер большого пакетного файла равен по крайней мере размеру пакета; увидеть --batch-size вариант для repack подкоманда в git multi-pack-index. Размер пакета по умолчанию равен нулю, что является особым случаем, когда делается попытка перепаковать все файлы пакета в один файл пакета.

И:

maintenance: добавить автоматическое условие инкрементальной переупаковки
^{Подписано: Деррик Столи}

Задача инкрементной переупаковки обновляет индекс нескольких пакетов, удаляя файлы пакетов, которые были заменены новыми пакетами, а затем переупаковывает пакет небольших файлов пакетов в более крупный файл пакета. Эта инкрементная переупаковка выполняется быстрее, чем перезапись всех данных объекта, но медленнее, чем некоторые другие действия по обслуживанию.
' maintenance.incremental-repack.autoПараметр config указывает, сколько файлов пакетов должно существовать вне индекса multi-pack перед запуском шага.
Эти pack-файлы могут быть созданы с помощью ' git fetch^{( man)}'или с помощью задачи свободных объектов.
Значение по умолчанию - 10.
Установка параметра в ноль отключает задачу с ' --auto', а при отрицательном значении задача запускается каждый раз.

git configтеперь включает в свою справочную страницу:

maintenance.incremental-repack.auto
Этот целочисленный параметр конфигурации определяет, как часто incremental-repack задача должна выполняться как часть git maintenance run --auto. Если ноль, то incremental-repack задача не будет работать с --autoвариант. Отрицательное значение заставит задачу запускаться каждый раз. В противном случае положительное значение означает, что команда должна запускаться, когда количество файлов пакетов, не включенных в индекс нескольких пакетов, не меньше значения maintenance.incremental-repack.auto. Значение по умолчанию - 10.

В Git 2.30 (первый квартал 2021 г.) добавлены части " git maintenance" ^{( man),} чтобы упростить написание записей crontab (и других конфигураций системы планирования) для него.

См. Фиксацию 0016b61, фиксацию 61f7a38, фиксацию a4cb1a2 (15 октября 2020 г.), фиксацию 2fec604, фиксацию 0c18b70, фиксацию 4950b2a, фиксацию b08ff1f (11 сентября 2020 г.) и фиксацию 1942d48 (28 августа 2020 г.) Деррик Столи (derrickstolee).
^{(Слияние Junio C Hamano -
gitster- в коммите 7660da1, 18 ноя 2020)}

maintenance: добавить руководство по устранению неполадок в документы
^{Помощник: Джунио С. Хамано.}
^{Подпись: Деррик Столи.}

' git maintenance run Подкоманда ⁽^man⁾ 'блокирует базу данных объектов, чтобы предотвратить конкуренцию параллельных процессов за ресурсы. Это важная мера безопасности для предотвращения возможного повреждения репозитория и потери данных.
Эта функция может привести к сбиванию с толку, если пользователь не знает об этом. Добавьте раздел УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ в " git maintenance^{( man)}'встроенная документация, в которой обсуждаются эти компромиссы.
Краткая версия этого раздела заключается в том, что Git не повредит ваш репозиторий, но если список запланированных задач занимает больше часа, некоторые запланированные задачи могут быть отброшены из-за этого конфликта базы данных объектов.
Например, длительная "ежедневная" задача в полночь может препятствовать выполнению "ежечасной" задачи в 01:00.
Возможно и обратное, но с меньшей вероятностью, если "ежечасные" задачи выполняются намного быстрее, чем "ежедневные" и "еженедельные" задачи.

git maintenanceтеперь включает в свою справочную страницу:

ПОИСК ПРОБЛЕМЫ
В git maintenanceКоманда предназначена для упрощения шаблонов обслуживания репозитория при минимизации времени ожидания пользователя во время выполнения команд Git. Доступны различные варианты конфигурации, позволяющие настроить этот процесс. Варианты обслуживания по умолчанию ориентированы на операции, которые выполняются быстро, даже в больших репозиториях.
Пользователи могут обнаружить некоторые случаи, когда запланированные задачи обслуживания не выполняются так часто, как предполагалось. Каждый git maintenance run блокирует базу данных объектов репозитория, что предотвращает другие параллельные git maintenance runкоманды из того же репозитория. Без этой защиты конкурирующие процессы могут покинуть репозиторий в непредсказуемом состоянии.
График фонового обслуживания запускается git maintenance runобрабатывает почасово. Каждый запуск выполняет "ежечасные" задачи. В полночь этот процесс также выполняет "ежедневные" задачи. В полночь первого дня недели этот процесс также выполняет "еженедельные" задачи. Один процесс проходит по каждому зарегистрированному репозиторию, выполняя запланированные задачи с определенной периодичностью. В зависимости от количества зарегистрированных репозиториев и их размеров этот процесс может занять больше часа. В этом случае несколько git maintenance runкоманды могут выполняться в одном и том же репозитории в одно и то же время, сталкиваясь с блокировкой базы данных объектов. В результате одна из двух задач не выполняется.
Если вы обнаружите, что для выполнения некоторых окон обслуживания требуется больше часа, подумайте об уменьшении сложности задач обслуживания. Например, gc задача намного медленнее, чем incremental-repackзадача. Однако это происходит за счет немного большей объектной базы данных. Подумайте о переносе более дорогих задач, чтобы они выполнялись реже.
Опытные пользователи могут подумать о планировании своих собственных задач обслуживания, используя график, отличный от того, который доступен через git maintenance startи параметры конфигурации Git. Эти пользователи должны знать о блокировке объектной базы данных и о том, как git maintenance runкоманды ведут себя. Далее git gc команда не должна сочетаться с git maintenance run команды. git gc изменяет объектную базу данных, но не принимает блокировку так же, как git maintenance run. Если возможно, используйте git maintenance run --task=gc вместо git gc.

user6309 20 окт '18 в 05:45 2018-10-20 05:45 · Answer 3 · 2018-10-20 05:45

Если вы контролируете git gc --auto состояние выхода (например, для обнаружения сбоя), это возвращаемое значение изменилось с помощью Git 2.20:

См. Коммит 3029970 (17 июля 2018 г.) Джонатана Нидера ( artagnon)
Помогает: Джефф Кинг ( peff )
^{(Объединено Юнио С Хамано -} gitster ^{- в комитете 993fa56 от 16 октября 2018 года)}

gc: выход из состояния 128 при ошибке
Значение -1 вернулся из cmd_gc gets распространяется на exit(), в результате чего статус выхода 255.
Вместо этого используйте die для более четкого сообщения об ошибке и контролируемого выхода.

Вместо " error: The last gc run reported the following. "Теперь у вас есть:

fatal: The last gc run reported the following

Как я могу узнать, что `git gc --auto` что-то сделал?

1 ответ

`maintenance`: создать базовую программу обслуживания

git-обслуживание (1)

ИМЯ

ОБЗОР

ОПИСАНИЕ

ПОДСКАЗКИ

`run`

ЗАДАНИЯ

`gc`

ПАРАМЕТРЫ

`--auto`

`maintenance`: заменить `run_auto_gc()`

`maintenance`: add --task option

`--task=<task>`

`maintenance`: создать конфигурацию обслуживания..enabled

`maintenance.<task>.enabled`

`maintenance`: заблокировать каталог объектов

`maintenance`: используйте указатели для проверки `--auto`

`maintenance`: добавить задачу фиксации графа

`commit-graph`

`maintenance`: добавить автоматическое условие для `commit-graph` задача

`maintenance.commit-graph.auto`

`maintenance`: проверить автоматическое состояние графика фиксации

`maintenance`: добавить задачу инкрементальной переупаковки

`incremental-repack`

`maintenance`: добавить автоматическое условие инкрементальной переупаковки

`maintenance.incremental-repack.auto`

`maintenance`: добавить руководство по устранению неполадок в документы

`gc`: выход из состояния 128 при ошибке

Как я могу узнать, что `git gc --auto` что-то сделал?

1 ответ

maintenance: создать базовую программу обслуживания

git-обслуживание (1)

ИМЯ

ОБЗОР

ОПИСАНИЕ

ПОДСКАЗКИ

run

ЗАДАНИЯ

gc

ПАРАМЕТРЫ

--auto

maintenance: заменить run_auto_gc()

maintenance: add --task option

--task=<task>

maintenance: создать конфигурацию обслуживания..enabled

maintenance.<task>.enabled

maintenance: заблокировать каталог объектов

maintenance: используйте указатели для проверки --auto

maintenance: добавить задачу фиксации графа

commit-graph

maintenance: добавить автоматическое условие для commit-graph задача

maintenance.commit-graph.auto

maintenance: проверить автоматическое состояние графика фиксации

maintenance: добавить задачу инкрементальной переупаковки

incremental-repack

maintenance: добавить автоматическое условие инкрементальной переупаковки

maintenance.incremental-repack.auto

maintenance: добавить руководство по устранению неполадок в документы

gc: выход из состояния 128 при ошибке

`maintenance`: создать базовую программу обслуживания

`run`

`gc`

`--auto`

`maintenance`: заменить `run_auto_gc()`

`maintenance`: add --task option

`--task=<task>`

`maintenance`: создать конфигурацию обслуживания..enabled

`maintenance.<task>.enabled`

`maintenance`: заблокировать каталог объектов

`maintenance`: используйте указатели для проверки `--auto`

`maintenance`: добавить задачу фиксации графа

`commit-graph`

`maintenance`: добавить автоматическое условие для `commit-graph` задача

`maintenance.commit-graph.auto`

`maintenance`: проверить автоматическое состояние графика фиксации

`maintenance`: добавить задачу инкрементальной переупаковки

`incremental-repack`

`maintenance`: добавить автоматическое условие инкрементальной переупаковки

`maintenance.incremental-repack.auto`

`maintenance`: добавить руководство по устранению неполадок в документы

`gc`: выход из состояния 128 при ошибке