git-maintenance

Имя

git-maintenance — выполнение задач для оптимизации данных репозитория Git

Краткое описание

git maintenance run [<options>]
git maintenance start [--scheduler=<scheduler>]
git maintenance (stop|register|unregister) [<options>]
git maintenance is-needed [<options>]

Описание

Выполняет задачи для оптимизации данных репозитория Git, ускоряя выполнение других команд Git и сокращая требования к хранилищу репозитория.

Команды Git, добавляющие данные в репозиторий, такие как git add или git fetch, оптимизированы для отзывчивой работы с пользователем. Эти команды не тратят время на оптимизацию данных Git, поскольку такие оптимизации масштабируются в зависимости от полного размера репозитория, а каждая из этих пользовательских команд выполняет сравнительно небольшое действие.

Команда git maintenance позволяет гибко выбирать способ оптимизации репозитория Git.

Подкоманды

run

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

start

Запускает обслуживание текущего репозитория. Выполняет те же изменения конфигурации, что и подкоманда register, а затем обновляет фоновый планировщик, чтобы он запускал git maintenance run --scheduled каждый час.

stop

Останавливает расписание фонового обслуживания. Текущий репозиторий не удаляется из списка обслуживаемых репозиториев на случай, если фоновое обслуживание будет запущено повторно позднее.

register

Инициализирует значения конфигурации Git, чтобы запланированное обслуживание запускалось для этого репозитория. Добавляет репозиторий в переменную конфигурации maintenance.repo в глобальной конфигурации текущего пользователя или в конфигурацию, указанную параметром --config-file, и включает некоторые рекомендуемые значения конфигурации для maintenance.<task>.schedule. Включённые задачи безопасно выполнять в фоновом режиме, не мешая процессам, выполняющимся в переднем плане.

Подкоманда register также задаёт для значения конфигурации maintenance.strategy значение incremental, если оно ещё не задано. Стратегия incremental использует следующее расписание для каждой задачи обслуживания:

gc: отключено.
commit-graph: каждый час.
prefetch: каждый час.
loose-objects: ежедневно.
incremental-repack: ежедневно.

git maintenance register также отключает обслуживание в переднем плане, задавая в текущем репозитории maintenance.auto = false. Этот параметр конфигурации сохранится и после выполнения команды git maintenance unregister.

unregister

Удаляет текущий репозиторий из списка фонового обслуживания. Репозиторий удаляется только из списка, заданного в конфигурации. Фоновые процессы обслуживания не останавливаются.

Подкоманда unregister сообщит об ошибке, если текущий репозиторий ещё не зарегистрирован. Используйте параметр --force, чтобы команда завершилась успешно, даже если текущий репозиторий не зарегистрирован.

is-needed

Проверяет, требуется ли запуск обслуживания, не запуская его. Завершает работу с кодом состояния 0, если обслуживание необходимо запустить, и с кодом 1 в противном случае. Рекомендуется использовать с флагом --auto.

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

Задачи

commit-graph

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

prefetch

Задача prefetch обновляет каталог объектов, загружая последние объекты со всех зарегистрированных удалённых репозиториев. Для каждого удалённого репозитория выполняется команда git fetch. Настроенный refspec изменяется так, чтобы все запрошенные ссылки помещались в refs/prefetch/. Кроме того, теги не обновляются.

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

С помощью конфигурации remote.<name>.skipFetchAll можно исключить предварительную загрузку для определённого удалённого репозитория.

gc

Очищает ненужные файлы и оптимизирует локальный репозиторий. «GC» означает «сборка мусора», но эта задача выполняет множество более мелких операций. Для больших репозиториев эта задача может быть ресурсоёмкой, поскольку она перепаковывает все объекты Git в один файл пакета. В некоторых ситуациях она также может мешать работе, так как удаляет устаревшие данные. Подробнее о сборке мусора в Git см. в git-gc[1].

loose-objects

Задача loose-objects очищает свободные объекты и помещает их в файлы пакетов. Во избежание состояний гонки с параллельно выполняющимися командами Git используется двухэтапный процесс. Сначала удаляются все свободные объекты, уже имеющиеся в файле пакета; параллельные процессы Git будут искать данные объектов в файле пакета, а не среди свободных объектов. Затем создаётся новый файл пакета (с префиксом «loose-»), содержащий набор свободных объектов.

Размер набора по умолчанию составляет пятьдесят тысяч объектов, чтобы задача не выполнялась слишком долго в репозиториях с большим количеством свободных объектов. Используйте параметр конфигурации maintenance.loose-objects.batchSize, чтобы изменить это значение; значение 0 снимает ограничение.

Задача gc записывает недостижимые объекты как свободные, чтобы их можно было очистить на следующем этапе, если они не будут повторно добавлены в файл пакета. Поэтому не рекомендуется одновременно включать задачи loose-objects и gc.

incremental-repack

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

pack-refs

Задача pack-refs собирает отдельные файлы ссылок в один файл. Это ускоряет операции, которым требуется перебрать множество ссылок. Дополнительные сведения см. в git-pack-refs[1].

reflog-expire

Задача reflog-expire удаляет из журнала ссылок все записи, срок хранения которых истёк. Дополнительные сведения см. в git-reflog[1].

rerere-gc

Задача rerere-gc выполняет сборку мусора для устаревших записей в кэше rerere. Дополнительные сведения см. в git-rerere[1].

worktree-prune

Задача worktree-prune удаляет устаревшие или повреждённые рабочие деревья. Дополнительные сведения см. в git-worktree[1].

Параметры

--auto: При использовании вместе с подкомандой run запускает задачи обслуживания только при достижении определённых пороговых значений. Например, задача gc запускается, когда число свободных объектов превышает число, указанное в параметре конфигурации gc.auto, или когда число файлов пакетов превышает значение параметра конфигурации gc.autoPackLimit. Несовместим с параметром --schedule. При использовании вместе с подкомандой is-needed проверяет, достигнуты ли требуемые пороговые значения, не запуская обслуживание.
--schedule: При использовании вместе с подкомандой run запускает задачи обслуживания только при выполнении определённых временных условий, заданных значением конфигурации maintenance.<task>.schedule для каждой задачи <task>. Это значение конфигурации задаёт количество секунд, прошедших с момента последнего запуска задачи, согласно значению конфигурации maintenance.<task>.lastRun. Проверяются задачи, указанные в параметрах --task=<task>, либо задачи, для которых параметр maintenance.<task>.enabled имеет значение true.
--quiet: Не выводит ход выполнения и другие сведения в stderr.
--task=<task>: Если этот параметр указан один или несколько раз, выполняются только заданные задачи в указанном порядке. Если аргументы --task=<task> не указаны, рассматриваются только задачи, для которых параметр конфигурации maintenance.<task>.enabled имеет значение true. Список допустимых значений <task> см. в разделе TASKS.
--scheduler=auto|crontab|systemd-timer|launchctl|schtasks: При использовании вместе с подкомандой start задаёт планировщик для ежечасного, ежедневного и еженедельного запуска git maintenance run. Допустимые значения <scheduler>: auto, crontab (POSIX), systemd-timer (Linux), launchctl (macOS) и schtasks (Windows). Если указано значение auto, используется подходящий для платформы планировщик; в Linux используется systemd-timer, если он доступен, иначе — crontab. Значение по умолчанию — auto.

Устранение неполадок

Команда 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 gc используйте git maintenance run --task=gc.

В следующих разделах описаны механизмы фонового обслуживания, реализованные в git maintenance start, и способы их настройки.

Фоновое обслуживание в системах POSIX

Стандартный механизм планирования фоновых задач в системах POSIX — cron(8). Этот инструмент выполняет команды по заданному расписанию. Текущий список задач пользователя, запланированных таким образом, можно посмотреть, выполнив команду crontab -l. Расписание, созданное командой git maintenance start, выглядит примерно так:

# BEGIN GIT MAINTENANCE SCHEDULE
# The following schedule was created by Git
# Any edits made in this region might be
# replaced in the future by a Git command.

0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly
0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily
0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly

# END GIT MAINTENANCE SCHEDULE

Комментарии обозначают область расписания, созданную Git. Любые изменения в этой области будут полностью удалены командой git maintenance stop или перезаписаны командой git maintenance start.

Запись crontab задаёт полный путь к исполняемому файлу git, чтобы выполняемая команда git совпадала с той, с помощью которой была вызвана команда git maintenance start, независимо от PATH. Если один и тот же пользователь запускает git maintenance start с несколькими исполняемыми файлами Git, будет использоваться только последний из них.

Эти команды используют git for-each-repo --config=maintenance.repo для запуска git maintenance run --schedule=<frequency> для каждого репозитория, перечисленного в многозначном параметре конфигурации maintenance.repo. Обычно эти значения загружаются из глобальной конфигурации пользователя. Затем процесс git maintenance определяет, какие задачи обслуживания настроены для запуска в каждом репозитории с заданной периодичностью <frequency>, используя параметры конфигурации maintenance.<task>.schedule. Эти значения загружаются из глобальной конфигурации или конфигурации репозитория.

Если значений конфигурации недостаточно для желаемого расписания фонового обслуживания, можно создать собственное расписание. При запуске команды crontab -e в редакторе откроется пользовательское расписание cron. В редакторе можно добавить собственные строки расписания. Можно взять за основу приведённое выше расписание по умолчанию или обратиться к документации crontab(5), где описаны более сложные способы планирования. Используйте полный путь и приёмы --exec-path из расписания по умолчанию, чтобы убедиться, что запускаются правильные исполняемые файлы.

Фоновое обслуживание в системах Linux с systemd

Хотя Linux поддерживает cron, в зависимости от дистрибутива cron может быть необязательным пакетом, который не обязательно установлен. В современных дистрибутивах Linux его заменяют таймеры systemd.

Если доступны пользовательские таймеры systemd, они будут использоваться вместо cron.

В этом случае git maintenance start создаст пользовательские модули таймеров systemd и запустит таймеры. Текущий список задач пользователя, запланированных таким образом, можно посмотреть, выполнив команду systemctl --user list-timers. Таймеры, созданные командой git maintenance start, выглядят примерно так:

$ systemctl --user list-timers
NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
Thu 2021-04-29 19:00:00 CEST 42min left    Thu 2021-04-29 18:00:11 CEST 17min ago  git-maintenance@hourly.timer git-maintenance@hourly.service
Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago    git-maintenance@daily.timer  git-maintenance@daily.service
Mon 2021-05-03 00:00:00 CEST 3 days left   Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service

Для каждого параметра --schedule=<frequency> регистрируется один таймер.

Определения модулей systemd можно посмотреть в следующих файлах:

~/.config/systemd/user/git-maintenance@.timer
~/.config/systemd/user/git-maintenance@.service
~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer

Команда git maintenance start перезапишет эти файлы и повторно запустит таймер с помощью systemctl --user, поэтому для настройки следует создать файл переопределения, то есть файл с суффиксом .conf в каталоге ~/.config/systemd/user/git-maintenance@.service.d.

Команда git maintenance stop остановит пользовательские таймеры systemd и удалит перечисленные выше файлы.

Дополнительные сведения см. в systemd.timer(5).

Фоновое обслуживание в системах macOS

Хотя macOS технически поддерживает cron, для использования crontab -e требуются повышенные привилегии, а запущенный процесс не получает полного пользовательского контекста. Без полного пользовательского контекста Git и его помощники учётных данных не могут получить доступ к сохранённым учётным данным, поэтому некоторые задачи обслуживания не работают.

Вместо этого команда git maintenance start взаимодействует с инструментом launchctl, рекомендованным способом планирования задач по времени в macOS. Для планирования обслуживания через git maintenance (start|stop) требуются некоторые возможности launchctl, доступные только в macOS 10.11 и более поздних версиях.

Запланированные задачи пользователя хранятся в XML-файлах .plist в каталоге ~/Library/LaunchAgents/. Текущие зарегистрированные задачи можно просмотреть с помощью следующей команды:

$ ls ~/Library/LaunchAgents/org.git-scm.git*
org.git-scm.git.daily.plist
org.git-scm.git.hourly.plist
org.git-scm.git.weekly.plist

Для каждого параметра --schedule=<frequency> регистрируется одна задача. Чтобы узнать, как XML-формат описывает расписание, откройте один из этих файлов .plist в редакторе и изучите элемент <array> после элемента <key>StartCalendarInterval</key>.

Команда git maintenance start перезапишет эти файлы и повторно зарегистрирует задачи с помощью launchctl, поэтому для настройки следует создать собственные файлы .plist с уникальными именами. Аналогично, команда git maintenance stop отменит регистрацию задач с помощью launchctl и удалит файлы .plist.

Дополнительные сведения о расширенной настройке фоновых задач см. в launchctl.plist(5).

Фоновое обслуживание в системах Windows

Windows не поддерживает cron и использует собственную систему планирования фоновых задач. Команда git maintenance start использует команду schtasks для добавления задач в эту систему. Все фоновые задачи можно просмотреть в приложении «Планировщик заданий». Добавленные Git задачи называются по шаблону Git Maintenance (<frequency>). Графический интерфейс планировщика заданий позволяет просматривать эти задачи, но можно также экспортировать их в XML-файлы и изучить подробности в них.

Обратите внимание: поскольку Git — консольное приложение, эти фоновые задачи создают консольное окно, видимое текущему пользователю. Это можно изменить вручную, выбрав в планировщике заданий параметр «Выполнять независимо от того, вошёл ли пользователь в систему». Для этого изменения требуется ввести пароль, поэтому команда git maintenance start не выбирает этот параметр по умолчанию.

Если вы хотите настроить фоновые задачи, переименуйте их, чтобы последующие вызовы git maintenance (start|stop) не перезаписывали ваши пользовательские задачи.

Конфигурация

Всё содержимое ниже этой строки в данном разделе выборочно включено из документации git-config[1]. Содержимое совпадает с тем, что находится там:

maintenance.auto

Этот логический параметр конфигурации определяет, будут ли некоторые команды выполнять git maintenance run --auto после завершения своей обычной работы. Значение по умолчанию — true.

maintenance.autoDetach

Многие команды Git запускают автоматическое обслуживание после записи данных в репозиторий. Этот логический параметр конфигурации определяет, будет ли это автоматическое обслуживание выполняться на переднем плане или процесс обслуживания будет отсоединён и продолжит работу в фоновом режиме.

Если значение не задано, в качестве резервного используется значение gc.autoDetach. Если не заданы оба параметра, значение по умолчанию — true, то есть процесс обслуживания будет отсоединён.

maintenance.strategy

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

Стратегию обслуживания можно дополнительно настроить, задав параметры maintenance.<task>.enabled и maintenance.<task>.schedule. Если они заданы, эти значения используются вместо значений по умолчанию, предусмотренных параметром maintenance.strategy.

Возможны следующие стратегии:

none: эта стратегия означает, что задачи вообще не выполняются. Это стратегия по умолчанию для запланированного обслуживания.
gc: эта стратегия выполняет задачу gc.
geometric: эта стратегия выполняет геометрическую перепаковку pack-файлов и поддерживает вспомогательные структуры данных в актуальном состоянии. Стратегия удаляет устаревшие записи из reflog и рабочие деревья, которые больше невозможно найти. Если при геометрической перепаковке было бы принято решение выполнить перепаковку всех объектов в один файл, стратегия создаёт cruft-пак для всех недостижимых объектов. Объекты, уже входящие в cruft-пак, будут удалены по истечении срока хранения.

Эта стратегия перепаковки полностью заменяет стратегию gc и рекомендуется для больших репозиториев. Это стратегия по умолчанию для ручного обслуживания.
incremental: этот параметр оптимизирует выполнение небольших задач обслуживания, не удаляющих данные. При этом задача gc не планируется, а задачи prefetch и commit-graph выполняются каждый час, задачи loose-objects и incremental-repack — ежедневно, а задача pack-refs — еженедельно. При ручном обслуживании репозитория выполняется задача gc.

maintenance.<task>.enabled

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

maintenance.<task>.schedule

Этот параметр конфигурации определяет, будет ли указанная задача <task> выполняться при вызове команды git maintenance run --schedule=<frequency>. Значение должно быть одним из следующих: "hourly", "daily" или "weekly".

maintenance.commit-graph.auto

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

maintenance.loose-objects.auto

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

maintenance.loose-objects.batchSize

Этот целочисленный параметр конфигурации определяет максимальное число отдельных объектов, записываемых в pack-файл во время выполнения задачи loose-objects. Значение по умолчанию — пятьдесят тысяч. Укажите значение 0, чтобы снять ограничение.

maintenance.incremental-repack.auto

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

maintenance.geometric-repack.auto

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

maintenance.geometric-repack.splitFactor

Этот целочисленный параметр конфигурации задаёт коэффициент геометрической последовательности. Дополнительные сведения см. в описании параметра --geometric= в git-repack[1]. Значение по умолчанию — 2.

maintenance.reflog-expire.auto

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

maintenance.rerere-gc.auto

Этот целочисленный параметр конфигурации определяет, как часто задача rerere-gc должна выполняться в рамках git maintenance run --auto. Если значение равно нулю, задача rerere-gc не будет выполняться при использовании параметра --auto. Отрицательное значение заставляет выполнять задачу каждый раз. В противном случае любое положительное значение означает, что команда будет выполняться, если каталог "rr-cache" существует и содержит хотя бы одну запись, независимо от того, устарела она или нет. В дальнейшем этот эвристический метод может быть усовершенствован. Значение по умолчанию — 1.

maintenance.worktree-prune.auto

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

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-maintenance