git-config

Данные после ключевого слова gitdir и двоеточия используются как шаблон glob. Если расположение каталога .git соответствует шаблону, условие включения выполнено.

Расположение .git может быть обнаружено автоматически или получено из переменной окружения $GIT_DIR. Если репозиторий обнаружен автоматически через файл .git (например, в подмодулях или связанном рабочем дереве), расположением .git считается конечное местоположение каталога .git, а не место расположения файла .git.

Шаблон может содержать стандартные подстановочные символы glob, а также два дополнительных символа — **/ и /**, которые могут соответствовать нескольким компонентам пути. Подробности см. в gitignore[5]. Для удобства:

То же, что и gitdir, но при сопоставлении регистр не учитывается (например, в файловых системах, нечувствительных к регистру).

Данные после ключевого слова onbranch и двоеточия считаются шаблоном со стандартными подстановочными символами glob и двумя дополнительными символами — **/ и /**, которые могут соответствовать нескольким компонентам пути. Если мы находимся в рабочем дереве, где имя текущей выбранной ветки соответствует шаблону, условие включения выполнено.

Если шаблон заканчивается на /, к нему автоматически добавляется **. Например, шаблон foo/ становится foo/**. Иными словами, он соответствует всем веткам, начинающимся с foo/. Это полезно, если ветки организованы иерархически и требуется применить конфигурацию ко всем веткам этой иерархии.

Данные после этого ключевого слова и двоеточия считаются шаблоном со стандартными подстановочными символами glob и двумя дополнительными символами — **/ и /**, которые могут соответствовать нескольким компонентам. При первом появлении этого ключевого слова остальные файлы конфигурации просматриваются на наличие удалённых URL-адресов (без применения каких-либо значений). Если найден хотя бы один удалённый URL-адрес, соответствующий шаблону, условие включения выполнено.

Файлы, включённые этим параметром (непосредственно или косвенно), не могут содержать удалённые URL-адреса.

Обратите внимание: в отличие от других условий includeIf, разрешение этого условия зависит от информации, которая ещё неизвестна на момент чтения условия. Типичный сценарий использования — наличие этого параметра в системной или глобальной конфигурации, а удалённого URL-адреса — в локальной; поэтому при разрешении условия требуется предварительное сканирование. Чтобы избежать проблемы «курицы и яйца», при которой потенциально включаемые файлы могут влиять на решение об их включении, Git разрывает этот цикл, запрещая этим файлам влиять на разрешение таких условий (и тем самым запрещая им объявлять удалённые URL-адреса).

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

Если переменная принимает логическое значение, для true и false допускается множество синонимов; регистр символов во всех них не учитывается.

При преобразовании значения в каноническую форму с помощью спецификатора типа --type=bool git config гарантирует, что результатом будет «true» или «false» (в нижнем регистре).

Значение многих переменных, задающих различные размеры, можно снабдить суффиксами k, M,…​, означающими «умножить число на 1024», «на 1024×1024» и т. д.

Значение переменной, принимающей цвет, представляет собой список цветов (не более двух: один для переднего плана, один для фона) и атрибутов (сколько угодно), разделённых пробелами.

Допустимы следующие основные цвета: normal, black, red, green, yellow, blue, magenta, cyan, white и default. Первый указанный цвет задаёт передний план, второй — фон. Все основные цвета, кроме normal и default, имеют яркий вариант, который можно указать, добавив перед цветом префикс bright, например brightred.

Цвет normal не изменяет цвет. Он эквивалентен пустой строке, но его можно использовать в качестве цвета переднего плана, если задаётся только цвет фона (например, «normal red»).

Цвет default явно сбрасывает цвет до значения по умолчанию терминала, например для сброса фона. Хотя поведение зависит от терминала, обычно это не то же самое, что «white black».

Цвета также можно задавать числами от 0 до 255; для них используется режим ANSI с 256 цветами (однако учтите, что не все терминалы могут его поддерживать). Если терминал поддерживает эту возможность, можно также задавать 24-битные значения RGB в шестнадцатеричном формате, например #ff0ab3, или 12-битные значения RGB, например #f1b, эквивалентные 24-битному цвету #ff11bb.

Допустимые атрибуты: bold, dim, ul, blink, reverse, italic и strike (для зачёркнутых букв). Положение атрибутов относительно цветов (до, после или между ними) не имеет значения. Отдельные атрибуты можно отключить, поставив перед ними no или no- (например, noreverse, no-ul и т. д.).

Псевдоатрибут reset сбрасывает все цвета и атрибуты перед применением указанных параметров окрашивания. Например, reset green задаст зелёный цвет переднего плана и фон по умолчанию без активных атрибутов.

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

Для предопределённых цветовых слотов Git атрибуты сбрасываются в начале каждого элемента окрашенного вывода. Поэтому настройка color.decorate.branch на black окрасит имя ветки в обычный black, даже если предыдущий элемент в той же строке вывода (например, открывающая скобка перед списком имён веток в выводе log --decorate) окрашен с помощью bold или другого атрибута. Однако пользовательские форматы журнала могут использовать более сложное многослойное окрашивание, и в таких случаях могут быть полезны отрицательные формы.

Переменной, принимающей путь, можно задать строку, начинающуюся с «~/» или «~user/»; к такой строке применяется обычная подстановка тильды: ~/ заменяется значением $HOME, а ~user/ — домашним каталогом указанного пользователя.

Если путь начинается с %(prefix)/, оставшаяся часть интерпретируется как путь относительно «префикса среды выполнения» Git, то есть относительно расположения, в котором установлен Git. Например, %(prefix)/bin/ указывает на каталог, в котором находится исполняемый файл Git. Если Git собран без поддержки префикса среды выполнения, вместо него используется префикс, заданный при сборке. В маловероятном случае, когда нужно указать буквальный путь, который не должен подвергаться подстановке not, перед ним необходимо поставить ./, например так: ./%(prefix)/bin.

Если перед именем переменной конфигурации стоит :(optional), переменная считается несуществующей, если указанный путь не существует.

Указывает git add продолжать добавление файлов, если некоторые файлы не удаётся добавить из-за ошибок индексирования. Эквивалент параметра --ignore-errors команды git-add[1]. Переменная add.ignore-errors устарела, поскольку её имя не соответствует обычному соглашению об именовании переменных конфигурации.

Эти переменные управляют различными необязательными справочными сообщениями, призванными помочь новым пользователям. Если переменные не заданы, Git выводит сообщение вместе с инструкциями о том, как отключить его. Чтобы сообщить Git, что вы поняли проблему и больше не нуждаетесь в конкретном справочном сообщении, задайте соответствующей переменной значение false.

Эти сообщения предназначены для помощи пользователям и выводятся в стандартный поток ошибок. Если инструменты, запускающие Git как подпроцесс, считают их мешающими, они могут задать в окружении переменную GIT_ADVICE=0, чтобы отключить все справочные сообщения.

Псевдонимы команд для оболочки команды git[1]. Псевдонимы можно задавать в двух форматах:

Примеры:

# Without subsection (ASCII alphanumeric and dash only)
[alias]
    co = checkout
    st = status

# With subsection (allows any characters, including UTF-8)
[alias "hämta"]
    command = fetch
[alias "rätta till"]
    command = commit --amend

Если задан псевдоним Git, например:

$ git config --global alias.last "cat-file commit HEAD"
# Which is equivalent to
$ git config --global alias.last.command "cat-file commit HEAD"

git last эквивалентно git cat-file commit HEAD.

Чтобы избежать путаницы и проблем при использовании скриптов, псевдонимы, скрывающие существующие команды Git, игнорируются, за исключением устаревших команд. Аргументы разделяются пробелами; поддерживаются обычные правила экранирования и заключения в кавычки оболочки. Для заключения аргументов в кавычки можно использовать пару кавычек или обратную косую черту.

Обратите внимание, что первое слово псевдонима не обязательно должно быть командой. Это может быть параметр командной строки, передаваемый при вызове git. В частности, это полезно при использовании с -c для передачи разовых настроек или с -p для принудительного включения постраничного вывода. Например, можно определить loud-rebase = -c commit.verbose=true rebase, чтобы запуск git loud-rebase был эквивалентен git -c commit.verbose=true rebase. Кроме того, полезным будет псевдоним ps = -p status, поскольку git ps будет выводить постранично результат команды git status, хотя сама исходная команда этого не делает.

Если раскрытие псевдонима начинается с восклицательного знака, оно будет интерпретироваться как команда оболочки. Например, если определить alias.new = !gitk --all --not ORIG_HEAD, то вызов git new будет эквивалентен выполнению команды оболочки gitk --all --not ORIG_HEAD. Обратите внимание:

Если значение равно true, git-am[1] вызывает git-mailsplit[1] для патчей в формате mbox с параметром --keep-cr. В этом случае git-mailsplit[1] не будет удалять \r из строк, заканчивающихся на \r\n. Значение можно переопределить, указав --no-keep-cr в командной строке.

По умолчанию git-am[1] завершится с ошибкой, если патч не удастся применить без конфликтов. Если задать значение true, эта настройка указывает git-am[1] использовать трёхстороннее слияние, если в патче записана идентичность объектов blob, к которым его нужно применить, и эти объекты blob доступны локально (эквивалентно указанию параметра --3way в командной строке). По умолчанию установлено значение false.

При использовании git-am[1] добавляет к коммиту завершающий элемент Message-ID на основе заголовка электронного письма (см. git-interpret-trailers[1]). См. также параметры --message-id и --no-message-id.

Если задано значение change, указывает git apply игнорировать изменения в пробельных символах, как и параметр --ignore-space-change. Если задано одно из значений no, none, never, false, указывает git apply учитывать все различия в пробельных символах. См. git-apply[1].

Указывает git apply, как обрабатывать пробельные символы, как и параметр --whitespace. См. git-apply[1].

Ссылка на дерево в репозитории, из которого следует считывать атрибуты вместо файла .gitattributes в рабочем дереве. Если значение не разрешается в допустимый объект дерева, вместо него используется пустое дерево. Если используется переменная окружения GIT_ATTR_SOURCE или параметр командной строки --attr-source, эта переменная конфигурации не действует.

Регулярное выражение, используемое для сопоставления имён ссылок. Коммиты, на которые указывают ссылки, соответствующие этому шаблону (и отвечающие приведённым ниже критериям, например bitmapPseudoMerge.<name>.sampleRate и bitmapPseudoMerge.<name>.threshold), будут рассматриваться для включения в битовую карту псевдослияния.

Коммиты группируются в группы псевдослияния в зависимости от того, соответствуют ли шаблону — расширенному регулярному выражению — какие-либо ссылки, указывающие на данный коммит.

Внутри группы псевдослияния коммиты могут быть дополнительно сгруппированы в подгруппы на основе групп захвата в шаблоне. Эти подгруппы формируются из регулярных выражений путём объединения всех групп захвата регулярного выражения с - дефисом между ними.

Например, если шаблон — refs/tags/, то все теги (при условии, что они отвечают приведённым ниже критериям) будут считаться кандидатами в одну группу псевдослияния. Однако если шаблон — refs/remotes/([0-9])+/tags/, то теги с разных удалённых репозиториев будут сгруппированы в отдельные группы псевдослияния в зависимости от номера удалённого репозитория.

Определяет скорость, с которой уменьшается размер последовательных групп битовых карт псевдослияния. Значение должно быть неотрицательным. Этот параметр можно считать k в функции f(n) = C * n^-k, где f(n) — размер `n`-й группы.

Если задать скорость затухания равной 0, все группы будут иметь одинаковый размер. Если задать скорость затухания равной 1, размер начальной группы составит nth group to be 1/n. При более высоких значениях скорости затухания размер каждой следующей группы уменьшается всё быстрее. Значение по умолчанию — 1.

Если все группы имеют одинаковый размер, группы с более новыми коммитами могут использоваться реже, чем более ранние группы, поскольку ссылки на новые коммиты, вероятнее всего, будут обновляться чаще, чем ссылка на старый коммит.

Определяет долю коммитов без битовых карт (среди вершин ссылок), выбираемых для включения в нестабильную битовую карту псевдослияния. Значение должно быть больше 0 и меньше либо равно 1. Значение по умолчанию — 1.

Определяет минимальный возраст коммитов без битовых карт (как указано выше, среди вершин ссылок), которые могут быть включены в нестабильную битовую карту псевдослияния. Значение по умолчанию — 1.week.ago.

Определяет максимальное число коммитов псевдослияния, между которыми могут распределяться коммиты.

Для групп псевдослияния, шаблоны которых не содержат групп захвата, этот параметр применяется ко всем коммитам, соответствующим регулярному выражению. Для шаблонов, содержащих одну или несколько групп захвата, этот параметр применяется к каждой уникальной группе захвата.

Например, если группа захвата — refs/tags/, то этот параметр распределит все теги не более чем по maxMerges коммитам псевдослияния. Однако если группа захвата, например, — refs/remotes/([0-9]+)/tags/, то этот параметр будет применяться отдельно к набору тегов каждого удалённого репозитория.

Значение должно быть неотрицательным. Значение по умолчанию — 64.

Определяет минимальный возраст коммитов (как указано выше, среди вершин ссылок; при этом стабильные коммиты остаются кандидатами, даже если они уже охвачены битовой картой), которые могут быть включены в стабильную битовую карту псевдослияния. Значение по умолчанию — 1.month.ago.

При меньшем значении порога (например, 1.week.ago) будет создано больше стабильных групп (что потребует однократных затрат на создание), но со временем эти группы, вероятно, устареют. Более высокое значение приводит к противоположному результату: создаётся меньше стабильных групп, зато они полезнее.

Определяет размер (в количестве коммитов) стабильной битовой карты псевдослияния. Значение по умолчанию — 512.

Показывать пустое имя объекта коммита для граничных коммитов в git-blame[1]. По умолчанию этот параметр отключён.

Определяет цветовую схему для вывода команды blame. Значением может быть repeatedLines, highlightRecent или none (значение по умолчанию).

Задаёт формат дат в выводе git-blame[1]. Если параметр не задан, используется формат iso. Допустимые значения см. в описании параметра --date в git-log[1].

Показывать адрес электронной почты автора вместо его имени в git-blame[1]. По умолчанию этот параметр отключён.

Не считать корневые коммиты границами в git-blame[1]. По умолчанию этот параметр отключён.

Игнорировать ревизии, перечисленные в файле (по одному полному имени объекта на строку) при выполнении git-blame[1]. Пробелы и комментарии, начинающиеся с #, игнорируются. Этот параметр можно указывать несколько раз. Пустое имя файла сбрасывает список игнорируемых ревизий. Этот параметр обрабатывается перед параметром командной строки --ignore-revs-file.

Помечать в выводе git-blame[1] символом * строки, изменённые игнорируемой ревизией, которые не удалось отнести к другому коммиту.

Помечать в выводе git-blame[1] символом ? строки, изменённые игнорируемой ревизией, которые удалось отнести к другому коммиту.

Указывает git branch, git switch и git checkout настраивать новые ветки так, чтобы git-pull[1] правильно выполнял слияние с исходной веткой. Даже если этот параметр не задан, такое поведение можно выбрать отдельно для каждой ветки с помощью параметров --track и --no-track. Значение по умолчанию — true. Допустимые значения:

Если с помощью git branch, git switch или git checkout создаётся новая ветка, отслеживающая другую ветку, эта переменная указывает Git настроить pull на перебазирование вместо слияния (см. branch.<name>.rebase). Допустимые значения:

Сведения о настройке отслеживания одной веткой другой см. в branch.autoSetupMerge. Значение по умолчанию — never.

Эта переменная управляет сортировкой веток при их отображении командой git-branch[1]. Если параметр --sort=<value> не указан, значение этой переменной используется по умолчанию. Допустимые значения см. среди имён полей в git-for-each-ref[1].

Находясь в ветке <name>, параметр указывает git fetch и git push, из какого удалённого репозитория получать изменения или в какой отправлять их. Удалённый репозиторий для отправки можно переопределить с помощью remote.pushDefault (для всех веток). Удалённый репозиторий для отправки из текущей ветки можно дополнительно переопределить параметром branch.<name>.pushRemote. Если удалённый репозиторий не настроен или текущая ветка не выбрана, а в репозитории определено несколько удалённых репозиториев, для получения изменений по умолчанию используется origin, а для отправки — remote.pushDefault. Кроме того, . (точка) обозначает текущий локальный репозиторий (репозиторий-точку); см. последнее примечание ниже в описании branch.<name>.merge.

Находясь в ветке <name>, этот параметр переопределяет branch.<name>.remote для отправки изменений. Он также переопределяет remote.pushDefault при отправке из ветки <name>. Если вы получаете изменения из одного места (например, из вышестоящего репозитория), а отправляете в другое (например, в собственный репозиторий для публикации), задайте remote.pushDefault, чтобы указать удалённый репозиторий для отправки из всех веток, а этот параметр используйте для переопределения значения для конкретной ветки.

Вместе с branch.<name>.remote определяет вышестоящую ветку для данной ветки. Параметр указывает git fetch/git pull/git rebase, какую ветку объединять, а также может влиять на git push (см. push.default). Находясь в ветке <name>, он указывает git fetch спецификацию ссылок по умолчанию, которую следует пометить для слияния в FETCH_HEAD. Значение обрабатывается как удалённая часть спецификации ссылок и должно соответствовать ссылке, получаемой из удалённого репозитория, указанного в branch.<name>.remote. Сведения о слиянии используются командой git pull (которая сначала вызывает git fetch) для поиска ветки слияния по умолчанию. Без этого параметра команда git pull по умолчанию выполняет слияние с первой полученной спецификацией ссылок. Укажите несколько значений, чтобы выполнить слияние «осьминог». Если нужно настроить git pull так, чтобы она выполняла слияние в <name> из другой ветки локального репозитория, задайте для branch.<name>.merge нужную ветку, а для branch.<name>.remote используйте относительный путь . (точку).

Задаёт параметры слияния по умолчанию для ветки <name>. Синтаксис и поддерживаемые параметры совпадают с git-merge[1], однако значения параметров, содержащие пробельные символы, в настоящее время не поддерживаются.

Если значение равно true, перебазировать ветку <name> поверх полученной ветки вместо слияния с веткой по умолчанию из удалённого репозитория по умолчанию при запуске git pull. См. pull.rebase, если требуется настроить такое поведение не для отдельной ветки.

Если значение равно merges (или просто m), передать параметр --rebase-merges команде git rebase, чтобы включить локальные коммиты слияния в перебазирование (подробности см. в git-rebase[1]).

Если значение равно interactive (или просто i), перебазирование выполняется в интерактивном режиме.

ПРИМЕЧАНИЕ: эта операция потенциально опасна; не используйте её, если не понимаете последствий (подробности см. в git-rebase[1]).

Описание ветки; его можно изменить с помощью git branch --edit-description. Описание ветки автоматически добавляется в сопроводительное письмо format-patch или сводку request-pull.

Задаёт команду для запуска указанного браузера. Указанная команда выполняется в оболочке; URL передаются ей в качестве аргументов. (См. git-web--browse[1].)

Переопределяет путь к указанному инструменту, который может использоваться для просмотра справки в формате HTML (см. параметр -w в git-help[1]) или рабочего репозитория в gitweb (см. git-instaweb[1]).

Ключи bundle.* могут присутствовать в файле списка пакетов, найденном с помощью параметра git clone --bundle-uri. В настоящее время эти ключи не действуют, если указаны в файле конфигурации репозитория, но в будущем это изменится. Подробности см. в документе о проектировании URI пакетов.

Это целочисленное значение указывает версию формата списка пакетов, используемого в данном списке. В настоящее время допустимо только значение 1.

Это строковое значение должно быть равно all или any. Оно определяет, необходимы ли все объявленные пакеты для полного понимания содержащейся в них информации (all) или достаточно любого одного URI пакета из списка (any).

Если существует этот ключ со строковым значением, список пакетов предназначен для эффективной работы с инкрементными командами git fetch. Эвристика указывает на наличие дополнительных ключей для каждого пакета, помогающих определить, какое подмножество пакетов следует загрузить клиенту. В настоящее время поддерживается только значение creationToken.

Ключи bundle.<id>.* используются для описания отдельного элемента списка пакетов, сгруппированного под <id> для идентификации.

Это строковое значение задаёт URI, по которому Git может получить содержимое данного <id>. Этот URI может указывать на файл пакета или другой список пакетов.

При выполнении git checkout <something> или git switch <something>, если у вас только один удалённый репозиторий, Git может неявно перейти к переключению на ветку и её отслеживанию, например origin/<something>. Это перестаёт работать, как только появляется несколько удалённых репозиториев с ссылкой <something>. Этот параметр позволяет задать предпочтительный удалённый репозиторий, который всегда будет выбираться при разрешении неоднозначности. Обычно в качестве такого значения указывают origin.

В настоящее время этот параметр используется командами git-switch[1] и git-checkout[1], когда git checkout <something> или git switch <something> переключает на ветку <something> в другом удалённом репозитории, а также командой git-worktree[1], когда git worktree add указывает на ветку удалённого репозитория. В будущем этот параметр может использоваться и другими командами или функциями переключения.

Задаёт значение по умолчанию для параметра --guess или --no-guess в командах git checkout и git switch. См. git-switch[1] и git-checkout[1].

Количество параллельных рабочих процессов для обновления рабочего дерева. По умолчанию используется один процесс, то есть выполнение происходит последовательно. Если значение меньше единицы, Git использует столько рабочих процессов, сколько доступно логических ядер. Этот параметр и checkout.thresholdForParallelism влияют на все команды, выполняющие переключение. Например, checkout, clone, reset, sparse-checkout и т. д.

При параллельном переключении с небольшим количеством файлов затраты на запуск подпроцессов и межпроцессное взаимодействие могут превысить выигрыш от распараллеливания. Этот параметр позволяет задать минимальное количество файлов, при котором следует использовать параллельное переключение. Значение по умолчанию — 100.

Логический параметр, запрещающий git-clean удалять файлы без указания -f. По умолчанию включён.

Имя удалённого репозитория, создаваемого при клонировании репозитория. По умолчанию — origin. Его можно переопределить, передав параметр командной строки --origin команде git-clone[1].

Отклонять клонирование неглубокого репозитория; это поведение можно переопределить, передав параметр --reject-shallow в командной строке. См. git-clone[1].

Если задан фильтр частичного клонирования (см. --filter в git-rev-list[1]) и используется --recurse-submodules, применять этот фильтр также к подмодулям.

Логический параметр для включения или отключения цвета в подсказках (например, при ошибке отправки; список см. в advice.*). Может принимать значения always, false (или never) либо auto (или true); в последнем случае цвета используются только при выводе ошибок в терминал. Если параметр не задан, используется значение color.ui (по умолчанию — auto).

Использовать пользовательский цвет для подсказок.

Задаёт цвет аннотаций строк для git blame --color-by-age в зависимости от возраста строки.

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

Вместо абсолютной отметки времени можно использовать относительное время. Например, значение 2.weeks.ago подходит для обозначения всего, что старше двух недель.

По умолчанию используется blue,12 month ago,white,1 month ago,red: всё, что старше года, окрашивается в синий цвет; недавние изменения возрастом от месяца до года остаются белыми, а строки, добавленные за последний месяц, окрашиваются в красный цвет.

Использовать указанный цвет для аннотаций строк в git blame --color-lines, если они относятся к тому же коммиту, что и предыдущая строка. По умолчанию используется голубой цвет.

Логическое значение для включения или отключения цвета в выводе git-branch[1]. Может принимать значение always, false (или never) либо auto (или true); в последнем случае цвет используется только при выводе в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Использовать заданный цвет для раскрашивания ветвей. <slot> может принимать одно из значений: current (текущая ветвь), local (локальная ветвь), remote (ветвь удалённого отслеживания в refs/remotes/), upstream (отслеживаемая вышестоящая ветвь), plain (другие ссылки).

Использовать ли управляющие последовательности ANSI для раскрашивания исправлений. Если задано значение always, команды git-diff[1], git-log[1] и git-show[1] будут раскрашивать все исправления. Если задано значение true или auto, эти команды будут использовать цвет только при выводе в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Это не влияет на git-format-patch[1] и низкоуровневые команды git-diff-*. Значение можно переопределить в командной строке параметром --color[=<when>].

Использовать заданный цвет для раскрашивания различий. <slot> указывает, какую часть исправления раскрашивать заданным цветом; возможные значения: context (контекстный текст — plain является историческим синонимом), meta (метаинформация), frag (заголовок фрагмента), func (функция в заголовке фрагмента), old (удалённые строки), new (добавленные строки), commit (заголовки коммитов), whitespace (подсветка ошибок в пробельных символах), oldMoved (удалённые строки), newMoved (добавленные строки), oldMovedDimmed, oldMovedAlternative, oldMovedAlternativeDimmed, newMovedDimmed, newMovedAlternative newMovedAlternativeDimmed (подробности см. в настройке <mode> параметра --color-moved команды git-diff[1]), contextDimmed, oldDimmed, newDimmed, contextBold, oldBold и newBold (подробности см. в git-range-diff[1]).

Использовать заданный цвет для вывода git log --decorate. <slot> может принимать одно из значений: branch, remoteBranch, tag, stash или HEAD — соответственно для локальных ветвей, ветвей удалённого отслеживания, тегов, stash и HEAD; grafted — для пересаженных коммитов.

Если задано значение always, совпадения всегда подсвечиваются. При значении false (или never) подсветка не используется. При значении true или auto цвет используется только при выводе в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Использовать заданный цвет для раскрашивания вывода grep. <slot> указывает, какую часть строки раскрашивать заданным цветом; возможны следующие значения:

Если задано значение always, для интерактивных запросов и отображения данных всегда используется цвет (например, в командах "git-add --interactive" и "git-clean --interactive"). При значении false (или never) цвет не используется. При значении true или auto цвет используется только при выводе в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Использовать заданный цвет для вывода git add --interactive и git clean --interactive. <slot> может принимать значение prompt, header, help или error для четырёх разных типов обычного вывода интерактивных команд.

Логическое значение, определяющее, должны ли цветовые режимы auto раскрашивать вывод, передаваемый программе постраничного просмотра. По умолчанию включено; задайте значение false, если ваша программа постраничного просмотра не распознаёт коды цветов ANSI.

Логическое значение для включения или отключения цвета в сообщениях об ошибках при отправке изменений. Может принимать значение always, false (или never) либо auto (или true); в последнем случае цвет используется только при выводе сообщения об ошибке в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Использовать заданный цвет для сообщений об ошибках при отправке изменений.

Если значение задано, ключевые слова в начале строки подсвечиваются. Это ключевые слова "error", "warning", "hint" и "success"; регистр при сопоставлении не учитывается. Может принимать значение always, false (или never) либо auto (или true). Если значение не задано, используется значение color.ui (по умолчанию — auto).

Использовать заданный цвет для каждого ключевого слова удалённого узла. <slot> может принимать значение hint, warning, success или error, соответствующее ключевому слову.

Логическое значение для включения или отключения цвета в выводе git-show-branch[1]. Может принимать значение always, false (или never) либо auto (или true); в последнем случае цвет используется только при выводе в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Логическое значение для включения или отключения цвета в выводе git-status[1]. Может принимать значение always, false (или never) либо auto (или true); в последнем случае цвет используется только при выводе в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Использовать заданный цвет для раскрашивания статуса. <slot> может принимать одно из значений: header (текст заголовка сообщения о состоянии), added или updated (файлы, добавленные, но не зафиксированные), changed (файлы, изменённые, но не добавленные в индекс), untracked (файлы, не отслеживаемые Git), branch (текущая ветвь), nobranch (цвет предупреждения no branch; по умолчанию — красный), localBranch или remoteBranch (имена локальной и удалённой ветвей соответственно, если в кратком формате статуса отображаются сведения о ветви и её отслеживании), либо unmerged (файлы с неслитыми изменениями).

Логическое значение для включения или отключения цвета при отклонении отправки изменений. Может принимать значение always, false (или never) либо auto (или true); в последнем случае цвет используется только при выводе сообщения об ошибке в терминал. Если значение не задано, используется значение color.ui (по умолчанию — auto).

Использовать заданный цвет, если отправка изменений была отклонена.

Эта переменная задаёт значения по умолчанию для таких переменных, как color.diff и color.grep, которые управляют использованием цвета в разных группах команд. Область её действия будет расширяться по мере того, как новые команды будут получать настройки для задания значения параметра --color по умолчанию. Задайте значение false или never, если хотите, чтобы команды Git не использовали цвет без явного включения с помощью другой настройки или параметра --color. Задайте значение always, если хотите, чтобы цвет использовался для всего вывода, не предназначенного для обработки программами; задайте значение true или auto (значение по умолчанию начиная с Git 1.8.4), если хотите, чтобы такой вывод раскрашивался при отправке в терминал.

Указывает, должны ли поддерживаемые команды выводить данные в несколько столбцов. Эта переменная содержит список параметров, разделённых пробелами или запятыми:

Эти параметры задают условия включения функции (по умолчанию — never):

Эти параметры задают способ заполнения таблицы (по умолчанию — column). Если не заданы ни always, ни never, ни auto, задание любого из этих параметров подразумевает always.

Наконец, эти параметры можно сочетать с параметром компоновки (по умолчанию — nodense):

Указывает, следует ли выводить список ветвей команды git branch в несколько столбцов. Подробности см. в column.ui.

Задаёт способ компоновки списка элементов команды git clean -i, которая всегда выводит файлы и каталоги в несколько столбцов. Подробности см. в column.ui.

Указывает, следует ли выводить неотслеживаемые файлы команды git status в несколько столбцов. Подробности см. в column.ui.

Указывает, следует ли выводить список тегов команды git tag в несколько столбцов. Подробности см. в column.ui.

Этот параметр переопределяет значение по умолчанию для параметра --cleanup в git commit. Подробности см. в git-commit[1]. Изменение значения по умолчанию может быть полезно, если вы всегда хотите сохранять в сообщении журнала строки, начинающиеся с символа комментария (core.commentChar, по умолчанию #); в этом случае следует указать git config commit.cleanup whitespace (обратите внимание: если вы так поступите, строки справки, начинающиеся с символа комментария, потребуется удалить из шаблона журнала коммитов самостоятельно).

Логическое значение, указывающее, следует ли подписывать все коммиты с помощью GPG. Использование этого параметра при выполнении таких операций, как перебазирование, может привести к подписанию большого количества коммитов. Чтобы не вводить парольную фразу GPG несколько раз, можно использовать агент.

Логическое значение, включающее или отключающее добавление сведений о состоянии в шаблон сообщения коммита при подготовке сообщения в редакторе. По умолчанию — true.

Задаёт путь к файлу, который будет использоваться в качестве шаблона для новых сообщений коммитов.

Логическое значение или целое число, задающее уровень подробности для git commit. Подробности см. в git-commit[1].

Задаёт версию номеров поколений, используемую при записи или чтении файла commit-graph. Если указана версия 1, исправленные даты коммитов не будут записываться или считываться. По умолчанию — 2.

Задаёт значение по умолчанию для параметра --max-new-filters команды git commit-graph write (см. git-commit-graph[1]).

Если значение равно true, команда git commit-graph write по умолчанию вычисляет и записывает фильтры Блума для изменённых путей, что равносильно передаче параметра --changed-paths. Если значение равно false или не задано, фильтры Блума для изменённых путей записываются во время выполнения git commit-graph write только в том случае, если фильтры уже есть в текущем файле commit-graph. Это соответствует поведению команды git commit-graph write по умолчанию без параметра --[no-]changed-paths. Чтобы перезаписать файл commit-graph без фильтров, используйте параметр --no-changed-paths. Параметр командной строки --[no-]changed-paths всегда имеет приоритет над этой настройкой. По умолчанию не задано.

Устарел. Эквивалентен commitGraph.changedPathsVersion=-1, если значение равно true, и commitGraph.changedPathsVersion=0, если значение равно false. (Если также задан commitGraph.changedPathVersion, приоритет имеет commitGraph.changedPathsVersion.)

Задаёт версию фильтров Блума для изменённых путей, которые Git будет читать и записывать. Допустимые значения: -1, 0, 1 или 2. Обратите внимание: версии выше 1 могут быть несовместимы со старыми версиями Git, которые пока не поддерживают эти версии. Будьте осторожны при работе в среде с разными версиями.

По умолчанию — -1.

Если задано значение -1, Git использует версию фильтров Блума для изменённых путей, имеющуюся в репозитории, а если фильтров нет — версию 1.

Если задано значение 0, Git не считывает фильтры Блума, а при необходимости записи записывает фильтры Блума версии 1.

Если задано значение 1, Git считывает только фильтры Блума версии 1 и записывает фильтры Блума версии 1.

Если задано значение 2, Git считывает только фильтры Блума версии 2 и записывает фильтры Блума версии 2.

Дополнительные сведения см. в git-commit-graph[1].

Этот параметр используется только git-completion.bash для добавления команд в список автодополнения или удаления их из него. Обычно автодополнение доступно только для команд porcelain и некоторых других выбранных команд. В эту переменную можно добавить другие команды, разделив их пробелами. Если поставить перед командой -, она будет удалена из существующего списка.

Сообщает Git, следует ли учитывать бит исполнения файлов в рабочем дереве.

Некоторые файловые системы сбрасывают бит исполнения при извлечении файла, отмеченного как исполняемый, или устанавливают его при извлечении неисполняемого файла. git-clone[1] или git-init[1] проверяют, корректно ли файловая система обрабатывает бит исполнения, и при необходимости автоматически устанавливают эту переменную.

Однако репозиторий может находиться в файловой системе, которая корректно обрабатывает режимы файлов, и при его создании этой переменной присваивается значение true, но позднее репозиторий может стать доступен из другой среды, которая теряет режим файла (например, при экспорте ext4 через подключение CIFS или при работе с репозиторием, созданным в Cygwin, из Git for Windows или Eclipse). В таком случае может потребоваться установить для этой переменной значение false. См. git-update-index[1].

По умолчанию значение равно true (если core.filemode не указан в файле конфигурации).

(Только для Windows) Если значение равно true, вновь созданные каталоги и файлы, имена которых начинаются с точки, помечаются как скрытые. Если задано значение dotGitOnly, скрытым будет только каталог .git/, а остальные файлы, имена которых начинаются с точки, скрыты не будут. По умолчанию используется режим dotGitOnly.

Внутренняя переменная, включающая различные обходные решения для улучшения работы Git в файловых системах, не чувствительных к регистру, таких как APFS, HFS+, FAT, NTFS и другие. Например, если при просмотре каталога Git ожидает файл «Makefile», но обнаруживает «makefile», он считает, что это тот же файл, и продолжает учитывать его как «Makefile».

По умолчанию значение равно false, однако git-clone[1] или git-init[1] проверяют файловую систему и при создании репозитория устанавливают core.ignoreCase в true, если это необходимо.

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

Этот параметр используется только реализацией Git для Mac OS. Если core.precomposeUnicode=true, Git отменяет разложение Unicode в именах файлов, выполняемое Mac OS. Это полезно при совместном использовании репозитория в Mac OS и Linux или Windows. (Требуется Git for Windows версии 1.7.10 или выше либо Git под cygwin 1.7.) Если значение равно false, Git полностью прозрачно обрабатывает имена файлов, что обеспечивает обратную совместимость со старыми версиями Git.

Если задано значение true, не разрешается извлекать пути, которые файловая система HFS+ сочла бы эквивалентными .git. По умолчанию в Mac OS значение равно true, а в остальных системах — false.

Если задано значение true, не разрешается извлекать пути, которые могут вызвать проблемы в файловой системе NTFS, например конфликтовать с короткими именами формата 8.3. По умолчанию в Windows значение равно true, а в остальных системах — false.

Если задано значение true, для этого рабочего каталога включается встроенный демон мониторинга файловой системы (git-fsmonitor--daemon[1]).

Как и мониторы файловой системы на основе хуков, встроенный монитор может ускорить команды Git, которым требуется обновить индекс Git (например, git status) в рабочем каталоге с большим количеством файлов. Встроенный монитор избавляет от необходимости устанавливать и обслуживать сторонний инструмент.

В настоящее время встроенный монитор файловой системы доступен лишь на ограниченном наборе поддерживаемых платформ. Сейчас к ним относятся Windows и MacOS.

В противном случае эта переменная содержит путь к команде-хуку «fsmonitor».

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

См. раздел «fsmonitor-watchman» в githooks[5].

Обратите внимание: если вы одновременно используете несколько версий Git, например одну в командной строке, а другую в среде разработки, определение core.fsmonitor было расширено и теперь допускает логические значения наряду с путями к хукам. Версии Git 2.35.1 и более ранние не распознают логические значения и будут считать значения «true» или «false» путями к хукам, которые следует вызвать. В версиях Git с 2.26 по 2.35.1 по умолчанию используется протокол хуков V2, а при сбое мониторинг fsmonitor отключается (выполняется полное сканирование). В версиях Git до 2.26 по умолчанию используется протокол хуков V1; они молча предполагают, что изменений для отчёта нет (сканирование не выполняется), поэтому команды проверки состояния могут выдавать неполные результаты. Поэтому перед использованием встроенного монитора файловой системы рекомендуется обновить все версии Git.

Задаёт версию протокола, используемую при вызове хука «fsmonitor».

В настоящее время доступны версии 1 и 2. Если параметр не задан, сначала проверяется версия 2, а в случае сбоя — версия 1. В версии 1 для определения файлов, изменившихся с указанного момента времени, в качестве входных данных используется временная метка, однако некоторые мониторы, например Watchman, при работе с временными метками подвержены состояниям гонки. В версии 2 используется непрозрачная строка, позволяющая монитору возвращать данные для определения изменившихся файлов без состояний гонки.

Если значение равно false, различия ctime между индексом и рабочим деревом игнорируются; это полезно, когда время изменения inode регулярно меняется по причинам, не связанным с Git (например, из-за сканеров файловой системы или некоторых систем резервного копирования). См. git-update-index[1]. По умолчанию значение равно true.

Если значение равно true, используется функция разделённого индекса. См. git-update-index[1]. По умолчанию значение равно false.

Определяет, что делать с кэшем неотслеживаемых файлов в индексе. Если эта переменная не задана или имеет значение keep, кэш сохраняется. Если задано значение true, кэш будет автоматически добавлен. Если задано значение false, кэш будет автоматически удалён. Прежде чем задать значение true, убедитесь, что mtime в вашей системе работает правильно. См. git-update-index[1]. По умолчанию используется значение keep, если только не включён параметр feature.manyFiles, который по умолчанию устанавливает для этой настройки значение true.

Если значение не задано или равно default, проверяется множество полей структуры stat, чтобы определить, изменился ли файл с момента последнего обращения к нему Git. Если для этой переменной конфигурации задано значение minimal, при проверке исключаются доли секунды в mtime и ctime, uid и gid владельца файла, номер inode (а также номер устройства, если Git был собран с его использованием); проверяются только целые секунды mtime (и ctime, если задано значение core.trustCtime) и размер файла.

Некоторые реализации Git не оставляют пригодных для использования значений в отдельных полях (например, JGit); исключение этих полей из сравнения в режиме minimal может улучшить совместимость, если один и тот же репозиторий одновременно используется этими системами.

Команды, выводящие пути (например, ls-files, diff), заключают «необычные» символы в имени пути в двойные кавычки и экранируют их обратными косыми чертами так же, как в языке C экранируются управляющие символы (например, \t для TAB, \n для LF, \\ для обратной косой черты), а также байты со значениями выше 0x80 (например, восьмеричная последовательность \302\265 для символа «микро» в UTF-8). Если для этой переменной задано значение false, байты выше 0x80 больше не считаются «необычными». Двойные кавычки, обратная косая черта и управляющие символы экранируются независимо от значения этой переменной. Обычный пробел не считается «необычным». Многие команды могут выводить имена путей без изменений с помощью параметра -z. По умолчанию значение равно true.

Задаёт тип окончания строк, используемый в рабочем каталоге для файлов, помеченных как текстовые (либо атрибутом text, либо параметром text=auto, если Git автоматически распознаёт содержимое как текст). Допустимые значения: lf, crlf и native; последнее использует окончания строк, принятые на данной платформе. По умолчанию используется значение native. Дополнительные сведения о преобразовании окончаний строк см. в gitattributes[5]. Обратите внимание: это значение игнорируется, если для core.autocrlf задано значение true или input.

Если значение равно true, Git проверяет, обратимо ли преобразование CRLF при включённом преобразовании окончаний строк. Git проверяет, изменяет ли команда файл в рабочем дереве прямо или косвенно. Например, после фиксации файла его извлечение должно восстановить исходный файл в рабочем дереве. Если при текущем значении core.autocrlf это невозможно, Git отклонит файл. Переменной можно присвоить значение «warn»; в этом случае Git лишь предупредит о необратимом преобразовании, но продолжит операцию.

Преобразование CRLF сопряжено с небольшим риском повреждения данных. Если оно включено, Git преобразует CRLF в LF при фиксации и LF в CRLF при извлечении. Файл, содержащий смесь LF и CRLF до фиксации, не может быть восстановлен Git. Для текстовых файлов это правильное поведение: окончания строк исправляются так, чтобы в репозитории использовались только LF. Однако для двоичных файлов, ошибочно классифицированных как текстовые, преобразование может повредить данные.

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

К сожалению, невозможно отличить желаемый результат очистки текстовых файлов со смешанными окончаниями строк от нежелательного повреждения двоичных файлов. В обоих случаях CRLF удаляются необратимым образом. Для текстовых файлов это правильно, поскольку CRLF — окончания строк, а преобразование CRLF в двоичных файлах повреждает данные.

Обратите внимание: эта проверка безопасности не гарантирует, что извлечение создаст файл, идентичный исходному, при других значениях core.eol и core.autocrlf; гарантия действует только для текущих значений. Например, текстовый файл с LF будет принят при значении core.eol=lf, а позднее может быть извлечён при значении core.eol=crlf; в этом случае полученный файл будет содержать CRLF, хотя исходный файл содержал LF. Однако в обоих рабочих деревьях окончания строк будут согласованными: либо все LF, либо все CRLF, но никогда не смешанными. Файл со смешанными окончаниями строк будет обнаружен механизмом core.safecrlf.

Установка для этой переменной значения «true» равносильна установке атрибута text в значение «auto» для всех файлов и установке core.eol в значение «crlf». Задайте значение true, если в рабочем каталоге вы хотите использовать окончания строк CRLF, а в репозитории используются LF. Этой переменной можно присвоить значение input; в этом случае преобразование при выводе не выполняется.

Список кодировок, разделённых запятыми и/или пробелами, для которых Git выполняет проверку обратного преобразования UTF-8, если они указаны в атрибуте working-tree-encoding (см. gitattributes[5]). По умолчанию используется значение SHIFT-JIS.

Если значение равно false, символические ссылки извлекаются в виде небольших обычных файлов, содержащих текст ссылки. git-update-index[1] и git-add[1] не будут менять записанный тип на обычный файл. Полезно для файловых систем, таких как FAT, которые не поддерживают символические ссылки.

По умолчанию значение равно true, однако git-clone[1] или git-init[1] проверяют файловую систему и при создании репозитория устанавливают core.symlinks в false, если это необходимо.

«Прокси-команда», запускаемая (как command host port) вместо прямого подключения к удалённому серверу при получении данных по протоколу Git. Если значение переменной задано в формате «КОМАНДА для ДОМЕНА», команда применяется только к именам хостов, заканчивающимся указанной строкой домена. Эту переменную можно задавать несколько раз; значения проверяются в указанном порядке, и используется первое совпавшее.

Переопределяется переменной окружения GIT_PROXY_COMMAND (которая всегда применяется ко всем доменам без особой обработки «для»).

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

Если эта переменная задана, команды git fetch и git push будут использовать указанную команду вместо ssh при подключении к удалённой системе. Команда задаётся в том же формате, что и переменная окружения GIT_SSH_COMMAND, и переопределяется, если эта переменная окружения задана.

Если значение равно true, Git не будет использовать вызовы lstat() для обнаружения изменений файлов, устанавливая бит «assume-unchanged» для отслеживаемых файлов, которые он одинаково обновил и в индексе, и в рабочем дереве.

Если файлы изменяются вне Git, пользователь должен будет явно подготовить изменённые файлы (например, см. раздел Examples в git-update-index[1]). Обычно Git не обнаруживает изменения таких файлов.

Это полезно в системах, где вызовы lstat() выполняются очень медленно, например CIFS/Microsoft Windows.

По умолчанию значение равно false.

Вместо используемого по умолчанию формата «symref» для HEAD и других файлов символических ссылок на ссылки использовать символические ссылки файловой системы. Иногда это требуется для работы со старыми скриптами, которые ожидают, что HEAD будет символической ссылкой.

Эта настройка устарела и будет удалена в Git 3.0. Символические ссылки на ссылки всегда будут записываться в виде текстовых symref.

При объявлении указателей доступной истории из альтернативного репозитория используйте указанную команду оболочки вместо git-for-each-ref[1]. Первый аргумент — абсолютный путь к альтернативному репозиторию. Вывод должен содержать по одному шестнадцатеричному идентификатору объекта в каждой строке (то есть такой же, как вывод git for-each-ref --format='%(objectname)).

Обратите внимание: обычно нельзя напрямую поместить git for-each-ref в значение конфигурации, поскольку эта команда не принимает путь к репозиторию в качестве аргумента (однако приведённую выше команду можно обернуть в скрипт оболочки).

При выводе ссылок из альтернативного репозитория выводить только ссылки, начинающиеся с указанного префикса. Префиксы сопоставляются так же, как если бы они были переданы в качестве аргументов git-for-each-ref[1]. Чтобы указать несколько префиксов, разделите их пробелами. Если задан параметр core.alternateRefsCommand, настройка core.alternateRefsPrefixes не действует.

Если значение равно true, предполагается, что этот репозиторий является bare и не связан с рабочим каталогом. В этом случае ряд команд, которым требуется рабочий каталог, будет отключён, например git-add[1] или git-merge[1].

При создании репозитория это значение автоматически определяется командами git-clone[1] или git-init[1]. По умолчанию репозиторий, путь к которому оканчивается на «/.git», считается непустым (bare = false), а все остальные репозитории считаются пустыми (bare = true).

Задаёт путь к корню рабочего дерева. Если задана переменная окружения GIT_COMMON_DIR, core.worktree игнорируется и не используется для определения корня рабочего дерева. Это значение можно переопределить переменной окружения GIT_WORK_TREE и параметром командной строки --work-tree. Значение может быть абсолютным путём или путём относительно каталога .git, заданного с помощью --git-dir или GIT_DIR либо обнаруженного автоматически. Если задан --git-dir или GIT_DIR, но не заданы --work-tree, GIT_WORK_TREE и core.worktree, текущий рабочий каталог считается корнем рабочего дерева.

Обратите внимание: эта переменная учитывается, даже если она задана в файле конфигурации в подкаталоге «.git» каталога, а её значение отличается от пути к этому каталогу (например, в «/path/to/.git/config» для core.worktree указано «/different/path»); скорее всего, это ошибка конфигурации. При запуске команд Git в каталоге «/path/to» корнем рабочего дерева по-прежнему будет считаться «/different/path», что может привести к путанице, если вы не знаете, что делаете (например, создаёте в другом месте снимок того же индекса, доступный только для чтения, вместо обычного рабочего дерева репозитория).

Если значение равно true, Git будет создавать PID-файл рядом с файлами блокировки. Если не удаётся получить блокировку и существует PID-файл, Git может предоставить дополнительные диагностические сведения о процессе, удерживающем блокировку, в том числе о том, продолжает ли он работать. По умолчанию — false.

Имя PID-файла образуется вставкой ~pid перед суффиксом .lock. Например, если файл блокировки называется index.lock, PID-файл будет называться index~pid.lock. Файл содержит одну строку в формате pid <value>, за которой следует символ новой строки.

Включает журнал ссылок (reflog). Обновления ссылки <ref> записываются в файл «$GIT_DIR/logs/<ref>»: в него добавляются новые и старые SHA-1, дата и время, а также причина обновления, но только если файл существует. Если для этой переменной конфигурации задано значение true, отсутствующий файл «$GIT_DIR/logs/<ref>» автоматически создаётся для вершин веток (то есть в refs/heads/), удалённых ссылок (то есть в refs/remotes/), ссылок на заметки (то есть в refs/notes/) и символической ссылки HEAD. Если задано значение always, отсутствующий журнал ссылок автоматически создаётся для любой ссылки в refs/.

Эти сведения можно использовать, чтобы определить, какой коммит был вершиной ветки «2 дня назад».

По умолчанию значение равно true в репозитории, связанном с рабочим каталогом, и false в пустом репозитории.

Внутренняя переменная, определяющая формат репозитория и версию его структуры. См. gitrepository-layout[5].

При group (или true) репозиторий становится общим для нескольких пользователей в группе (все файлы и объекты становятся доступными для записи группе). При all (или world или everybody) репозиторий будет доступен для чтения всем пользователям, а также общим для группы. При umask (или false) Git будет использовать права доступа, сообщённые umask(2). При 0xxx, где 0xxx — восьмеричное число, файлы в репозитории будут иметь это значение режима доступа. 0xxx переопределит значение umask пользователя (в то время как остальные параметры переопределяют только запрошенные части значения umask пользователя). Примеры: 0660 сделает репозиторий доступным для чтения и записи владельцу и группе, но недоступным для остальных (эквивалентно group, если, например, umask равен 0022). 0640 — это репозиторий, доступный группе для чтения, но не для записи. См. git-init[1]. По умолчанию — false.

Если значение равно true, Git предупредит вас, если переданное имя ссылки неоднозначно и может соответствовать нескольким ссылкам в репозитории. По умолчанию — true.

Целое число от -1 до 9, задающее уровень сжатия по умолчанию. -1 — значение zlib по умолчанию. 0 означает отсутствие сжатия, а значения от 1 до 9 задают различные компромиссы между скоростью и размером; 9 — самое медленное. Если параметр задан, он служит значением по умолчанию для других переменных сжатия, таких как core.looseCompression и pack.compression.

Целое число от -1 до 9, задающее уровень сжатия объектов, не входящих в pack-файл. -1 — значение zlib по умолчанию. 0 означает отсутствие сжатия, а значения от 1 до 9 задают различные компромиссы между скоростью и размером; 9 — самое медленное. Если параметр не задан, используется значение core.compression. Если и оно не задано, используется 1 (максимальная скорость).

Количество байтов pack-файла, отображаемых в память за одну операцию отображения. Больший размер окна может позволить системе быстрее обрабатывать меньшее количество больших pack-файлов. Меньший размер окна отрицательно влияет на производительность из-за увеличения числа обращений к менеджеру памяти операционной системы, но может улучшить производительность при доступе к большому количеству больших pack-файлов.

По умолчанию — 1 MiB, если при компиляции был задан NO_MMAP; в противном случае — 32 MiB на 32-разрядных платформах и 1 GiB на 64-разрядных платформах. Это значение должно подходить всем пользователям и операционным системам. Скорее всего, корректировать его не потребуется.

Поддерживаются распространённые суффиксы единиц измерения: k, m или g.

Максимальное количество байтов из pack-файлов, одновременно отображаемых в память. Если для выполнения операции Git потребуется обратиться одновременно к большему объёму данных, он отменит отображение уже существующих областей, чтобы освободить виртуальное адресное пространство процесса.

По умолчанию — 256 MiB на 32-разрядных платформах и 32 TiB (фактически без ограничений) на 64-разрядных платформах. Это значение должно подходить всем пользователям и операционным системам, за исключением самых крупных проектов. Скорее всего, корректировать его не потребуется.

Поддерживаются распространённые суффиксы единиц измерения: k, m или g.

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

По умолчанию — 96 MiB на всех платформах. Это значение должно подходить всем пользователям и операционным системам, за исключением самых крупных проектов. Скорее всего, корректировать его не потребуется.

Поддерживаются распространённые суффиксы единиц измерения: k, m или g.

Размер файлов, считающихся «большими». Как описано ниже, это меняет поведение множества команд Git, а также способ хранения таких файлов в репозитории. Значение по умолчанию — 512 MiB. Поддерживаются распространённые суффиксы единиц измерения: k, m или g.

Файлы, размер которых превышает заданный предел:

Задаёт путь к файлу, содержащему шаблоны для описания путей, которые не следует отслеживать, в дополнение к .gitignore (для каждого каталога) и .git/info/exclude. По умолчанию используется $XDG_CONFIG_HOME/git/ignore. Если $XDG_CONFIG_HOME не задана или пуста, вместо неё используется $HOME/.config/git/ignore. См. gitignore[5].

Некоторым командам (например, интерфейсам svn и http), которые интерактивно запрашивают пароль, можно указать использовать внешнюю программу, заданную значением этой переменной. Её можно переопределить переменной среды GIT_ASKPASS. Если переменная не задана, используется значение переменной среды SSH_ASKPASS, а если оно отсутствует — простой запрос пароля. Внешней программе передаётся подходящий запрос в качестве аргумента командной строки, а пароль она должна вывести в STDOUT.

Задаёт путь к файлу с атрибутами (см. gitattributes[5]) в дополнение к .gitattributes (для каждого каталога) и .git/info/attributes. Значение по умолчанию — $XDG_CONFIG_HOME/git/attributes. Если $XDG_CONFIG_HOME не задана или пуста, вместо неё используется $HOME/.config/git/attributes.

По умолчанию Git ищет хуки в каталоге $GIT_DIR/hooks. Укажите здесь другой путь, например /etc/git/hooks, и Git будет искать хуки в этом каталоге, например /etc/git/hooks/pre-receive вместо $GIT_DIR/hooks/pre-receive.

Путь может быть абсолютным или относительным. Относительный путь отсчитывается от каталога, в котором запускаются хуки (см. раздел «DESCRIPTION» в githooks[5]).

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

Также можно полностью отключить все хуки, задав для core.hooksPath значение /dev/null. Обычно это рекомендуется только опытным пользователям и для отдельных команд, с помощью параметров конфигурации вида git -c core.hooksPath=/dev/null ....

Команды вроде commit и tag, позволяющие редактировать сообщения с помощью запуска редактора, используют значение этой переменной, если она задана, а переменная среды GIT_EDITOR не задана. См. git-var[1].

Команды вроде commit и tag, позволяющие редактировать сообщения, считают строку комментарием, если она начинается с этого символа, и удаляют такие строки после завершения работы редактора (по умолчанию #).

Если задано значение "auto", git-commit выберет символ, с которого не начинается ни одна строка в существующих сообщениях коммитов. Поддержка этого значения считается устаревшей и будет удалена в Git 3.0 из-за следующих ограничений:

Обратите внимание, что эти две переменные являются псевдонимами друг друга, и в современных версиях Git можно использовать со значением commentChar строку (например, // или ⁑⁕⁑). Версии Git до v2.45.0 игнорируют commentString, но отклоняют значение commentChar, состоящее более чем из одного байта ASCII. Если вы планируете использовать конфигурацию со старыми и новыми версиями Git, можно задать оба параметра:

[core]
# single character for older versions
commentChar = "#"
# string for newer versions (which will override commentChar
# because it comes later in the file)
commentString = "//"

Время в миллисекундах, в течение которого следует повторять попытки блокировки отдельной ссылки. Значение 0 означает, что повторных попыток не будет; -1 — что попытки будут повторяться бесконечно. По умолчанию — 100 (то есть повторные попытки в течение 100 мс).

Время в миллисекундах, в течение которого следует повторять попытки блокировки файла packed-refs. Значение 0 означает, что повторных попыток не будет; -1 — что попытки будут повторяться бесконечно. По умолчанию — 1000 (то есть повторные попытки в течение 1 секунды).

Программа просмотра текста для команд Git (например, less). Значение обрабатывается оболочкой. Приоритет выбора: переменная среды $GIT_PAGER, затем настройка core.pager, затем $PAGER и, наконец, значение по умолчанию, выбранное при компиляции (обычно less).

Если переменная среды LESS не задана, Git устанавливает её в FRX (если задана переменная среды LESS, Git не меняет её). Чтобы выборочно переопределить настройку LESS по умолчанию, можно задать для core.pager, например, значение less -S. Git передаст его оболочке, которая преобразует итоговую команду в LESS=FRX less -S. В среде параметр S не задан, но он передаётся в командной строке и указывает less обрезать длинные строки. Аналогично, задание для core.pager значения less -+F отключит в командной строке параметр F, заданный в среде, и деактивирует поведение less «выходить, если помещается на одном экране». Можно включать определённые флаги только для отдельных команд: например, задание для pager.blame значения less -S включает обрезку строк только для git blame.

Аналогично, если переменная среды LV не задана, Git устанавливает её в -c. Это значение можно переопределить, экспортировав LV с другим значением или задав для core.pager значение lv +c.

Список распространённых проблем с пробельными символами, разделённых запятыми, на которые следует обращать внимание. git diff будет использовать color.diff.whitespace для их выделения, а git apply --whitespace=error будет считать их ошибками. Чтобы отключить любой из параметров, перед ним можно указать - (например, -trailing-space):

Список компонентов репозитория, разделённых запятыми, которые следует защитить с помощью core.fsyncMethod при создании или изменении. Чтобы отключить защиту компонента, добавьте перед ним -. Незащищённые компоненты могут быть потеряны при некорректном завершении работы системы. Если у вас нет особых требований, рекомендуется оставить этот параметр пустым или выбрать одно из значений: committed, added или all.

При обработке этой настройки набор компонентов начинается со значения по умолчанию для платформы; отключённые компоненты удаляются, а дополнительные добавляются. none сбрасывает состояние, игнорируя значение по умолчанию для платформы.

Пустая строка сбрасывает конфигурацию fsync до значения по умолчанию для платформы. На большинстве платформ значение по умолчанию эквивалентно core.fsync=committed,-loose-object: оно обеспечивает хорошую производительность, но при некорректном завершении работы системы есть риск потери последних изменений.

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

Этот логический параметр включает fsync() при записи файлов объектов. Настройка устарела. Вместо неё используйте core.fsync.

Эта настройка влияет на данные, добавляемые в репозиторий Git в виде отдельных объектов. Если значение равно true, Git выполнит fsync или аналогичный системный вызов для сброса кэшей, чтобы отдельные объекты сохраняли целостность при некорректном завершении работы системы.

Включает параллельную предварительную загрузку индекса для таких операций, как git diff

Это может ускорить такие операции, как git diff и git status, особенно в файловых системах вроде NFS, для которых характерно слабое кэширование и, следовательно, относительно высокая задержка операций ввода-вывода. Если параметр включён, Git будет параллельно сравнивать индекс с данными файловой системы, позволяя выполнять операции ввода-вывода одновременно. По умолчанию — true.

Только для Windows: список имён переменных среды, разделённых запятыми, которые необходимо удалить перед запуском любого другого процесса. По умолчанию — PERL5LIB, поскольку Git for Windows настаивает на использовании собственного интерпретатора Perl.

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

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

При отображении сообщений коммитов также показывать заметки, хранящиеся в указанной ссылке. Ссылка должна быть полностью квалифицированной. Если указанная ссылка не существует, это не считается ошибкой, а означает, что заметки выводить не нужно.

По умолчанию используется "refs/notes/commits"; значение можно переопределить переменной среды GIT_NOTES_REF. См. git-notes[1].

Если значение равно true, Git будет читать файл графа коммитов (если он существует), чтобы разобрать структуру графа коммитов. По умолчанию — true. Дополнительные сведения см. в git-commit-graph[1].

Если задано значение false, ведёт себя так, как если бы в командной строке был указан параметр --no-replace-objects. Дополнительные сведения см. в git[1] и git-replace[1].

Использовать файл multi-pack-index для отслеживания нескольких pack-файлов с помощью одного индекса. Дополнительные сведения см. в git-multi-pack-index[1]. По умолчанию — true.

Включить функцию «разреженной выгрузки». Дополнительные сведения см. в git-sparse-checkout[1].

Включает «конический режим» функции разреженной выгрузки. Если файл sparse-checkout содержит ограниченный набор шаблонов, этот режим обеспечивает значительный прирост производительности. Чтобы использовать «неконический режим» и задавать более гибкие шаблоны, присвойте этой переменной значение false. Дополнительные сведения см. в git-sparse-checkout[1].

Задаёт длину сокращённых имён объектов. Если значение не задано или равно "auto", подходящая длина вычисляется исходя из приблизительного количества упакованных объектов в репозитории; предполагается, что её будет достаточно, чтобы сокращённые имена объектов оставались уникальными некоторое время. Если значение равно "no", сокращение не выполняется и имена объектов выводятся полностью. Минимальная длина — 4.

Максимальная глубина рекурсивного обхода дерева, допустимая для Git (например, глубина "a/b/cde/f" равна 4). Это предохранительный механизм, позволяющий Git корректно прервать операцию; обычно менять это значение не требуется. При компиляции Git с помощью MSVC значение по умолчанию — 512. В остальных случаях — 2048.

Указывает внешнюю вспомогательную программу, которую следует вызвать, когда требуются учётные данные — имя пользователя или пароль; программа может обращаться к внешнему хранилищу, чтобы не запрашивать учётные данные у пользователя. Обычно это имя вспомогательной программы для учётных данных с возможными аргументами, но также может быть абсолютный путь с аргументами или, если перед ним указано !, команды оболочки.

Обратите внимание, что можно задать несколько вспомогательных программ. Подробности и примеры см. в gitcredentials[7].

По умолчанию Git и настроенные вспомогательные программы для работы с учётными данными запрашивают данные у пользователя, если требуются новые учётные данные. Многие из этих программ могут использовать сохранённые учётные данные, если они ещё действительны. Чтобы исключить интерактивные запросы со стороны Git, задайте credential.interactive=false. Некоторые вспомогательные программы для работы с учётными данными также учитывают этот параметр.

При получении учётных данных считать компонент "path" URL-адреса http или https значимым. По умолчанию — false. Дополнительные сведения см. в gitcredentials[7].

По умолчанию в именах пользователей и узлов, отображаемых в запросе пароля, не допускаются управляющие символы (по умолчанию они кодируются в формате URL). Чтобы изменить это поведение, задайте для этого параметра значение false.

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

Если для сетевой аутентификации не задано имя пользователя, использовать это имя по умолчанию. См. credential.<context>.* ниже и gitcredentials[7].

Любые из перечисленных выше параметров credential.* можно применять выборочно к отдельным учётным данным. Например, параметр "credential.https://example.com.username" задаёт имя пользователя по умолчанию только для подключений по https к example.com. Подробности о сопоставлении URL-адресов см. в gitcredentials[7].

Указывает git-credential-cache—​daemon игнорировать SIGHUP, а не завершать работу.

Время в миллисекундах, в течение которого git-credential-store повторяет попытки при блокировке файла учётных данных. Значение 0 означает, что повторные попытки не выполняются; -1 означает, что попытки выполняются бесконечно. Значение по умолчанию — 1000 (то есть повторять попытки в течение 1 с).

При использовании git diff для сравнения с файлами рабочего дерева не считать изменениями изменения только в stat. Вместо этого незаметно выполнять git update-index --refresh, чтобы обновлять кэшированную информацию stat для путей, содержимое которых в рабочем дереве совпадает с содержимым в индексе. По умолчанию этот параметр имеет значение true. Обратите внимание: это влияет только на Porcelain-команды git diff, но не на низкоуровневые команды diff, такие как git diff-files.

Разделённый запятыми список параметров --dirstat, задающих поведение по умолчанию параметра --dirstat для git-diff[1] и подобных команд. Значения по умолчанию можно переопределить в командной строке (с помощью --dirstat=<param>,...). Резервные значения по умолчанию (если они не изменены параметром diff.dirstat) — changes,noncumulative,3. Доступны следующие параметры:

Пример: следующая команда подсчитает изменённые файлы, игнорируя каталоги, на которые приходится менее 10% от общего количества изменённых файлов, и суммируя количество изменений во вложенных каталогах для родительских каталогов: files,10,cumulative.

Ограничить ширину части с именем файла в выводе --stat. Если задан, параметр применяется ко всем командам, формирующим вывод --stat, кроме format-patch.

Ограничить ширину части с графиком в выводе --stat. Если задан, параметр применяется ко всем командам, формирующим вывод --stat, кроме format-patch.

Формировать diff с <n> строками контекста вместо значения по умолчанию, равного 3. Это значение переопределяется параметром -U.

Показывать контекст между фрагментами diff, добавляя указанное количество строк и объединяя таким образом близко расположенные фрагменты. Это значение используется по умолчанию для параметра командной строки --inter-hunk-context.

Если эта переменная конфигурации задана, diff формируется не с помощью встроенных средств Git, а указанной командой. Значение можно переопределить переменной окружения GIT_EXTERNAL_DIFF. Команда вызывается с параметрами, описанными в разделе «Git Diffs» справки git[1]. Примечание: если требуется использовать внешнюю программу diff только для части файлов, вместо этого можно воспользоваться gitattributes[5].

Если этому логическому параметру присвоено значение true, команда diff.external должна возвращать код завершения 0, если считает входные файлы одинаковыми, или 1, если считает их различными, как diff(1). Если параметру присвоено значение false (по умолчанию), команда должна возвращать код завершения 0 независимо от того, одинаковы ли файлы. Любой другой код завершения приводит к сообщению Git о фатальной ошибке.

Задаёт значение по умолчанию для --ignore-submodules. Обратите внимание: это влияет только на Porcelain-команды git diff, но не на низкоуровневые команды diff, такие как git diff-files. При отображении незакоммиченных изменений этот параметр также учитывают команды git checkout и git switch. Если задать значение all, сводка по подмодулям, обычно отображаемая командами git commit и git status при установленном параметре status.submoduleSummary, будет отключена, если только это не переопределено параметром командной строки --ignore-submodules. На команды git submodule этот параметр не влияет. По умолчанию задано значение untracked, поэтому все неотслеживаемые подмодули игнорируются.

Если параметр задан, git diff использует пару префиксов, отличающуюся от стандартных a/ и b/ в зависимости от сравниваемых объектов. При включённой конфигурации в обратном выводе diff порядок префиксов также меняется на противоположный:

Если параметр задан, git diff не отображает префиксы исходного и целевого файлов.

Если параметр задан, git diff использует указанный префикс исходного файла. По умолчанию используется a/.

Если параметр задан, git diff использует указанный префикс целевого файла. По умолчанию используется b/.

Если параметру присвоено значение true, git diff не показывает изменения за пределами каталога и выводит пути относительно текущего каталога.

Файл, задающий порядок файлов в diff. Подробности см. в описании параметра -O команды git-diff[1]. Если diff.orderFile — относительный путь, он считается относительно корня рабочего дерева.

Количество файлов, рассматриваемых при полном поиске копирований и переименований; эквивалент параметра git diff -l. Если значение не задано, в настоящее время по умолчанию используется 1000. Эта настройка не действует, если поиск переименований отключён.

Определяет, выполняет ли Git поиск переименований и каким образом. Если задано значение false, поиск переименований отключён. Если задано значение true, включён базовый поиск переименований. Если задано значение copies или copy, Git также выполняет поиск копирований. По умолчанию используется true. Обратите внимание: это влияет только на Porcelain-команды git diff, такие как git-diff[1] и git-log[1], но не на низкоуровневые команды, например git-diff-files[1].

Логический параметр, отключающий стандартное поведение — вывод пробела перед каждой пустой строкой вывода. По умолчанию имеет значение false.

Задаёт формат отображения различий в подмодулях. Формат short показывает только имена коммитов в начале и в конце диапазона. Формат log перечисляет коммиты в диапазоне так же, как это делает summary команды git-submodule[1]. Формат diff показывает встроенный diff изменённого содержимого подмодуля. По умолчанию используется short.

Расширенное регулярное выражение POSIX, используемое для определения того, что считать «словом» при вычислении различий пословно. Последовательности символов, соответствующие регулярному выражению, являются «словами», все остальные символы считаются игнорируемыми пробельными символами.

Команда пользовательского драйвера diff. Подробности см. в gitattributes[5].

Если этому логическому параметру присвоено значение true, команда diff.<driver>.command должна возвращать код завершения 0, если считает входные файлы одинаковыми, или 1, если считает их различными, как diff(1). Если параметру присвоено значение false (по умолчанию), команда должна возвращать код завершения 0 независимо от того, одинаковы ли файлы. Любой другой код завершения приводит к сообщению Git о фатальной ошибке.

Регулярное выражение, которое драйвер diff должен использовать для распознавания заголовка фрагмента. Также можно использовать встроенный шаблон. Подробности см. в gitattributes[5].

Задайте этому параметру значение true, чтобы драйвер diff считал файлы бинарными. Подробности см. в gitattributes[5].

Команда, которую драйвер diff должен вызывать для создания преобразованной в текст версии файла. Результат преобразования используется для формирования удобочитаемого diff. Подробности см. в gitattributes[5].

Регулярное выражение, которое драйвер diff должен использовать для разделения слов в строке. Подробности см. в gitattributes[5].

Задайте этому параметру значение true, чтобы драйвер diff кэшировал результаты преобразования текста. Подробности см. в gitattributes[5].

Задайте этому параметру значение false, чтобы отключить эвристики, включённые по умолчанию и сдвигающие границы фрагментов diff для повышения удобочитаемости патчей.

Выбрать алгоритм diff. Доступны следующие варианты:

Подсвечивать ошибки в пробельных символах в строках diff context, old или new. Несколько значений разделяются запятыми; none сбрасывает предыдущие значения, default сбрасывает список до new, а all — сокращение для old,new,context. Ошибки в пробельных символах выделяются цветом color.diff.whitespace. Параметр командной строки --ws-error-highlight=<kind> переопределяет эту настройку.

Если задано допустимое значение <mode> или значение true, перемещённые строки в diff окрашиваются иначе. Описание допустимых режимов см. в --color-moved в справке git-diff[1]. Если задано просто значение true, используется цветовой режим по умолчанию. Если задано значение false, перемещённые строки не окрашиваются.

Если перемещённые строки окрашиваются, например, с помощью настройки diff.colorMoved, этот параметр определяет режим обработки пробелов. Описание допустимых режимов см. в --color-moved-ws в справке git-diff[1].

Управляет выбором инструмента diff, используемого командой git-difftool[1]. Эта переменная переопределяет значение, настроенное в merge.tool. В списке ниже приведены допустимые встроенные значения. Любое другое значение рассматривается как пользовательский инструмент diff и требует определения соответствующей переменной difftool.<tool>.cmd.

Управляет выбором инструмента diff, используемого командой git-difftool[1], если указан флаг -g/--gui. Эта переменная переопределяет значение, настроенное в merge.guitool. В списке ниже приведены допустимые встроенные значения. Любое другое значение рассматривается как пользовательский инструмент diff и требует определения соответствующей переменной difftool.<guitool>.cmd.

Задаёт команду для вызова указанного инструмента diff. Указанная команда выполняется в оболочке; доступны следующие переменные: LOCAL содержит имя временного файла с содержимым исходного образа diff, а REMOTE содержит имя временного файла с содержимым конечного образа diff.

Подробнее см. описание параметра --tool=<tool> в справке git-difftool[1].

Переопределяет путь к указанному инструменту. Полезно, если инструмент не находится в PATH.

Завершать difftool, если вызванный инструмент diff возвращает ненулевой статус завершения.

Подробнее см. описание параметра --trust-exit-code в справке git-difftool[1].

Запрашивать подтверждение перед каждым вызовом инструмента diff.

Задайте значение true, чтобы по умолчанию использовать diff.guitool (эквивалентно указанию аргумента --gui), или auto, чтобы выбирать diff.guitool или diff.tool в зависимости от наличия значения переменной окружения DISPLAY. По умолчанию используется значение false; в этом случае аргумент --gui необходимо указать явно, чтобы использовать diff.guitool.

Если не указано иное, указывать расширение нельзя, если core.repositoryFormatVersion не равно 1. См. gitrepository-layout[5].

Если число объектов, импортированных с помощью git-fast-import[1], меньше этого предела, объекты будут распакованы в отдельные файлы объектов. Если же число импортированных объектов равно этому пределу или превышает его, пакет будет сохранен как pack-файл. Сохранение пакета, созданного fast-import, может ускорить завершение операции импорта, особенно в медленных файловых системах. Если параметр не задан, вместо него используется значение transfer.unpackLimit.

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

Включает параметры конфигурации, недавно появившиеся в Git и рассматриваемые в качестве настроек по умолчанию в будущем. Параметры конфигурации из этой группы могут добавляться или удаляться в каждом выпуске, в том числе в минорных обновлениях. Из-за новизны этих параметров возможны непредвиденные взаимодействия между ними. Включите эту настройку, если хотите оставить отзыв об экспериментальных функциях. Новые значения по умолчанию:

Включает параметры конфигурации, оптимизирующие работу с репозиториями, в рабочем каталоге которых много файлов. При большом количестве файлов такие команды, как git status и git checkout, могут работать медленно; новые значения по умолчанию повышают производительность:

Этот параметр управляет тем, будет ли git fetch (и лежащая в его основе операция получения данных в git pull) рекурсивно получать данные для заполненных подмодулей. Параметру можно задать логическое значение или значение on-demand. Если задано логическое значение, команда fetch и pull при значении true безусловно рекурсивно обрабатывает подмодули, а при значении false не выполняет рекурсию. Если задано значение on-demand, команды fetch и pull выполняют рекурсию в заполненный подмодуль, только если суперпроект получает коммит, обновляющий ссылку подмодуля. По умолчанию используется значение on-demand или значение submodule.recurse, если оно задано.

Если установлено значение true, git-fetch-pack проверит все полученные объекты. О том, что именно проверяется, см. в transfer.fsckObjects. По умолчанию используется значение false. Если параметр не задан, вместо него используется значение transfer.fsckObjects.

Работает как fsck.<msg-id>, но используется командой git-fetch-pack[1], а не git-fsck[1]. Подробности см. в документации к fsck.<msg-id>.

Работает как fsck.skipList, но используется командой git-fetch-pack[1], а не git-fsck[1]. Подробности см. в документации к fsck.skipList.

Если число объектов, полученных по встроенному протоколу передачи Git, меньше этого предела, объекты будут распакованы в отдельные файлы объектов. Если число полученных объектов равно этому пределу или превышает его, полученный пакет будет сохранен как pack-файл после добавления всех отсутствующих базовых дельт. Сохранение пакета при отправке данных может ускорить завершение операции отправки, особенно в медленных файловых системах. Если параметр не задан, вместо него используется значение transfer.unpackLimit.

Если значение равно true, команда fetch будет автоматически вести себя так, как если бы в командной строке был указан параметр --prune. См. также remote.<name>.prune и раздел «ОБРЕЗКА» в git-fetch[1].

Если значение равно true, при очистке команда fetch будет автоматически вести себя так, как если бы был указан refspec refs/tags/*:refs/tags/*, если он еще не задан. Это позволяет задать одновременно этот параметр и fetch.prune, чтобы поддерживать соответствие ссылок upstream один к одному. См. также remote.<name>.pruneTags и раздел «ОБРЕЗКА» в git-fetch[1].

Если значение равно true, команда fetch попытается обновить все доступные удаленные репозитории. Это поведение можно переопределить, передав --no-all или явно указав один или несколько удаленных репозиториев для получения данных. По умолчанию используется значение false.

Управляет выводом состояния обновления ссылок. Допустимые значения: full и compact. Значение по умолчанию — full. Подробности см. в разделе «ВЫВОД» в git-fetch[1].

Управляет отправкой сведений о коммитах в локальном репозитории при согласовании содержимого pack-файла, который должен отправить сервер. Задайте значение consecutive, чтобы использовать алгоритм, который последовательно обходит коммиты и проверяет каждый из них. Задайте значение skipping, чтобы использовать алгоритм, пропускающий коммиты для более быстрого схождения, но способный привести к созданию pack-файла большего размера, чем необходимо. Задайте значение noop, чтобы вообще не отправлять никаких сведений: это почти наверняка приведет к созданию pack-файла большего размера, чем необходимо, но позволит пропустить этап согласования. Задайте значение default, чтобы отменить ранее заданные настройки и использовать поведение по умолчанию. Обычно по умолчанию используется значение consecutive, но если feature.experimental имеет значение true, по умолчанию используется значение skipping. Если задано неизвестное значение, команда git fetch завершится с ошибкой.

См. также параметры --negotiate-only и --negotiation-restrict команды git-fetch[1].

Задайте значение false, чтобы включить --no-show-forced-updates в командах git-fetch[1] и git-pull[1]. По умолчанию используется значение true.

Указывает максимальное число операций получения данных, выполняемых одновременно (для подмодулей или удаленных репозиториев, если действует параметр --multiple команды git-fetch[1]).

Значение 0 означает использование подходящего значения по умолчанию. Если параметр не задан, по умолчанию используется значение 1.

Для подмодулей эту настройку можно переопределить с помощью параметра конфигурации submodule.fetchJobs.

Задайте значение true, чтобы после каждой команды git fetch, загружающей pack-файл с удаленного репозитория, записывать граф коммитов. При использовании параметра --split в большинстве случаев поверх существующих файлов графа коммитов будет создаваться очень небольшой файл. Иногда эти файлы будут объединяться, и запись может занять больше времени. Обновленный файл графа коммитов повышает производительность многих команд Git, включая git merge-base, git push -f и git log --graph. По умолчанию используется значение false.

В этом значении хранится URI для загрузки данных об объектах Git из bundle URI перед выполнением инкрементальной выборки с исходного сервера Git. Это аналогично работе параметра --bundle-uri команды git-clone[1]. Команда git clone --bundle-uri задаст значение fetch.bundleURI, если в переданном bundle URI содержится список пакетов, организованный для инкрементальной выборки.

Если изменить это значение, а в репозитории задано значение fetch.bundleCreationToken, удалите это значение fetch.bundleCreationToken, прежде чем получать данные из нового bundle URI.

При инкрементальном получении данных с помощью fetch.bundleURI из списка пакетов, использующего эвристику «creationToken», в этом значении конфигурации хранится максимальное значение creationToken среди загруженных пакетов. Это значение позволяет избежать загрузки пакетов в будущем, если объявленное значение creationToken не превышает его.

Значения токена создания выбирает поставщик, обслуживающий конкретный bundle URI. Если изменить URI в параметре fetch.bundleURI, перед получением данных обязательно удалите значение параметра fetch.bundleCreationToken.

Команда, используемая для преобразования содержимого файла рабочего дерева в blob при добавлении файла в индекс. Подробности см. в gitattributes[5].

Команда, используемая для преобразования содержимого объекта blob в файл рабочего дерева при извлечении файла. Подробности см. в gitattributes[5].

Включает вложения multipart/mixed по умолчанию для format-patch. Значением также может быть строка в двойных кавычках: в этом случае вложения будут включены по умолчанию, а указанное значение будет использовано как разделитель. См. параметр --attach команды git-format-patch[1]. Чтобы отменить ранее заданное значение, задайте пустую строку.

Задает значение по умолчанию для параметра --from команды format-patch. Принимает логическое значение либо имя и адрес электронной почты. Если значение равно false, по умолчанию format-patch использует --no-from и непосредственно указывает авторов коммитов в поле «From:» писем с патчами. Если значение равно true, по умолчанию format-patch использует --from, указывая в поле «From:» писем с патчами ваши данные коммитера и добавляя в тело письма поле «From:», если данные отличаются. Если задано значение, не являющееся логическим, format-patch использует его вместо данных коммитера. По умолчанию используется значение false.

Задает значение по умолчанию для параметра --[no-]force-in-body-from команды format-patch. По умолчанию используется значение false.

Логическое значение, которое включает или отключает порядковые номера в темах писем с патчами. По умолчанию используется значение «auto»: нумерация включается, только если патчей больше одного. Ее можно включить или отключить для всех сообщений, задав значение «true» или «false». См. параметр --numbered команды git-format-patch[1].

Дополнительные заголовки электронной почты, включаемые в отправляемый по почте патч. См. git-format-patch[1].

Дополнительные получатели, включаемые в отправляемый по почте патч. См. параметры --to и --cc команды git-format-patch[1].

По умолчанию format-patch создает файлы с префиксом темы [PATCH]. Используйте эту переменную, чтобы изменить префикс.

Режим по умолчанию, определяющий, какие части сопроводительного письма будут заполнены описанием ветки при использовании format-patch. См. параметр --cover-from-description команды git-format-patch[1].

По умолчанию format-patch выводит подпись с номером версии Git. Используйте эту переменную, чтобы изменить значение по умолчанию. Задайте для этой переменной пустую строку ("") , чтобы отключить создание подписи.

Работает так же, как format.signature, но в качестве подписи используется содержимое файла, указанного этой переменной.

По умолчанию format-patch создает файлы с суффиксом .patch. Используйте эту переменную, чтобы изменить суффикс (если требуется, не забудьте включить точку).

Кодирует заголовки электронной почты с символами, отличными от ASCII, с помощью «Q-кодирования» (описанного в RFC 2047) для передачи по электронной почте. По умолчанию используется значение true.

Формат pretty по умолчанию для команд log/show/whatchanged. См. git-log[1], git-show[1], git-whatchanged[1].

Стиль потоков по умолчанию для git format-patch. Может иметь логическое значение или быть равным shallow или deep. Потоки shallow превращают каждое письмо в ответ на первое письмо серии; первое письмо выбирается в следующем порядке: сопроводительное письмо, --in-reply-to и первое письмо с патчем. Потоки deep превращают каждое письмо в ответ на предыдущее. Логическое значение true соответствует shallow, а значение false отключает потоки.

Логическое значение, позволяющее включить по умолчанию параметр -s/--signoff команды format-patch. Примечание: добавление завершающей строки Signed-off-by к патчу должно быть осознанным действием и означает, что вы подтверждаете наличие у вас прав на передачу этой работы на условиях той же лицензии с открытым исходным кодом. Дополнительное обсуждение см. в документе SubmittingPatches.

Логическое значение, определяющее, нужно ли создавать сопроводительное письмо при вызове format-patch. Кроме того, можно задать значение "auto", чтобы создавать сопроводительное письмо, только если патчей больше одного. По умолчанию — false.

Если параметр --commit-list-format не указан, format-patch использует значение этой переменной, чтобы определить формат записи каждого коммита. По умолчанию используется shortlog.

Задаёт пользовательский каталог для хранения полученных файлов вместо текущего рабочего каталога. Будут созданы все компоненты пути.

Максимальная длина имён выходных файлов, создаваемых командой format-patch; по умолчанию — 64. Может быть переопределена параметром командной строки --filename-max-length=<n>.

Логическое значение, позволяющее включить по умолчанию параметр --base=auto команды format-patch. Также можно задать значение "whenAble", чтобы разрешить включение --base=auto, если доступна подходящая база, но в противном случае пропускать добавление сведений о базе, не завершая работу format с ошибкой.

Задаёт значение по умолчанию для параметра --notes команды format-patch. Принимает логическое значение или ссылку, указывающую, откуда получать заметки. Если задано значение false, по умолчанию format-patch использует --no-notes. Если задано значение true, по умолчанию format-patch использует --notes. Если задано нелогическое значение, по умолчанию format-patch использует --notes=<ref>, где ref — это нелогическое значение. По умолчанию — false.

Чтобы использовать ссылку refs/notes/true, укажите именно это значение.

Эту настройку можно указать несколько раз, чтобы включить несколько ссылок на заметки. В таком случае она будет вести себя так же, как несколько переданных параметров --[no-]notes[=]. То есть значение true покажет заметки по умолчанию, значение <ref> также покажет заметки из указанной ссылки на заметки, а значение false отменит предыдущие настройки и скроет заметки.

Например,

[format]
        notes = true
        notes = foo
        notes = false
        notes = bar

покажет только заметки из refs/notes/bar.

Логическое значение, включающее надёжный формат "mboxrd", когда используется --stdout, чтобы экранировать строки "^>+From ".

Если задано, в патчах не показываются префиксы исходного файла и файла назначения. Это эквивалентно параметру diff.noprefix, используемому в git diff (но не учитываемому в format-patch). Обратите внимание: при включении этой настройки получателю созданных вами патчей потребуется применять их с параметром -p0.

Во время fsck Git может обнаружить проблемы в устаревших данных, которые не создавались бы текущими версиями Git и не передавались бы по сети, если бы был задан параметр transfer.fsckObjects. Эта возможность предназначена для поддержки работы с устаревшими репозиториями, содержащими такие данные.

Настройка fsck.<msg-id> будет учитываться командой git-fsck[1]. Чтобы принимать отправки таких данных, задайте вместо неё receive.fsck.<msg-id>, а чтобы клонировать или получать их — задайте fetch.fsck.<msg-id>.

Для краткости в оставшейся части документации рассматривается fsck.*, однако то же самое относится к соответствующим переменным receive.fsck.* и fetch.fsck.*.

В отличие от таких переменных, как color.ui и core.editor, переменные receive.fsck.<msg-id> и fetch.fsck.<msg-id> не будут использовать настройку fsck.<msg-id> в качестве запасного значения, если для них не заданы значения. Чтобы единообразно настроить параметры fsck для разных ситуаций, все три переменные должны иметь одинаковые значения.

Если задана настройка fsck.<msg-id>, ошибки можно преобразовать в предупреждения и наоборот, настроив параметр fsck.<msg-id>, где <msg-id> — это идентификатор сообщения fsck, а значение должно быть одним из следующих: error, warn или ignore. Для удобства fsck добавляет идентификатор сообщения в начало текста ошибки или предупреждения. Например, "missingEmail: invalid author/committer line - missing email" означает, что настройка fsck.missingEmail = ignore скроет эту проблему.

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

Если задать неизвестное значение fsck.<msg-id>, fsck завершит работу с ошибкой. Если же задать неизвестные значения receive.fsck.<msg-id> и fetch.fsck.<msg-id>, Git лишь выдаст предупреждение.

Поддерживаемые значения <msg-id> см. в разделе Fsck Messages справки git-fsck[1].

Путь к списку имён объектов (то есть по одному полному SHA-1 на строку), для которых известно, что они повреждены, но нефатально, и которые следует игнорировать. В Git версии 2.20 и новее игнорируются комментарии (#), пустые строки, а также начальные и конечные пробелы. В более старых версиях любая строка, не содержащая SHA-1, вызовет ошибку.

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

Как и переменная fsck.<msg-id>, эта переменная имеет соответствующие варианты receive.fsck.skipList и fetch.fsck.skipList.

В отличие от таких переменных, как color.ui и core.editor, переменные receive.fsck.skipList и fetch.fsck.skipList не будут использовать настройку fsck.skipList в качестве запасного значения, если для них не заданы значения. Чтобы единообразно настроить параметры fsck для разных ситуаций, все три переменные должны иметь одинаковые значения.

В более старых версиях Git (до 2.20) в документации указывалось, что список имён объектов должен быть отсортирован. Это никогда не было обязательным требованием: имена объектов могли располагаться в любом порядке. Однако при чтении списка отслеживалось, отсортирован ли он, для внутренней реализации двоичного поиска, которая могла работать быстрее с уже отсортированным списком. Если только список не был огромным, не было смысла специально сортировать его заранее. Начиная с Git версии 2.20 используется хеш-таблица, поэтому теперь предварительная сортировка списка не нужна.

По умолчанию демон fsmonitor отказывается работать с репозиториями на сетевых файловых системах. Настройка fsmonitor.allowRemote со значением true переопределяет это поведение. Учитывается только если для core.fsmonitor задано значение true.

Эта настройка, предназначенная для Mac OS и Linux, если она задана, указывает каталог, в котором создаётся сокет домена Unix для обмена данными между демоном fsmonitor и различными командами Git. Каталог должен находиться в нативной файловой системе. Учитывается только если для core.fsmonitor задано значение true.

Параметр глубины, используемый в алгоритме дельта-сжатия команды git gc --aggressive. По умолчанию равен 50 — значению по умолчанию параметра --depth, если не используется --aggressive.

Подробнее см. документацию по параметру --depth команды git-repack[1].

Параметр размера окна, используемый в алгоритме дельта-сжатия команды git gc --aggressive. По умолчанию равен 250 — это значительно больше стандартного значения --window, равного 10.

Подробнее см. документацию по параметру --window команды git-repack[1].

Если количество неупакованных объектов в репозитории превышает примерно это значение, команда git gc --auto упакует их. Некоторые команды Porcelain время от времени используют эту команду для выполнения лёгкой сборки мусора. Значение по умолчанию — 6700.

Если задать значение 0, отключится не только автоматическая упаковка, основанная на количестве неупакованных объектов, но и все остальные эвристики, которые git gc --auto обычно использует для определения необходимости выполнения работы, например gc.autoPackLimit.

Если количество пакетов, не помеченных файлом *.keep в репозитории, превышает это значение, команда git gc --auto объединит их в один пакет большего размера. Значение по умолчанию — 50. Значение 0 отключает эту функцию. Установка для gc.auto значения 0 также отключает её.

См. приведённую ниже переменную конфигурации gc.bigPackThreshold. Если она используется, то влияет на работу ограничения числа автоматически упаковываемых объектов.

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

Если значение ненулевое, при запуске git gc сохраняются все пакеты, не относящиеся к cruft-пакетам, размер которых превышает этот предел. Это очень похоже на --keep-largest-pack, за исключением того, что сохраняются все удовлетворяющие порогу пакеты, а не только самый большой. По умолчанию — ноль. Поддерживаются стандартные суффиксы единиц измерения k, m и g.

Обратите внимание: если количество сохраняемых пакетов превышает gc.autoPackLimit, эта переменная конфигурации игнорируется и все пакеты, кроме базового, перепаковываются. После этого количество пакетов должно стать меньше gc.autoPackLimit, и настройка gc.bigPackThreshold снова будет учитываться.

Если для нормальной работы команды git repack недостаточно расчётного объёма памяти, а gc.bigPackThreshold не задана, самый большой пакет также будет исключён (это равносильно запуску git gc с параметром --keep-largest-pack).

Если задано значение true, при запуске git-gc[1] команда gc перезапишет файл графа коммитов. При использовании git gc --auto граф коммитов будет обновлён, если потребуется обслуживание репозитория. Значение по умолчанию — true. Подробности см. в git-commit-graph[1].

Если файл gc.log существует, команда git gc --auto выведет его содержимое и завершится с нулевым кодом возврата, не запускаясь, если только файл не старше gc.logExpiry. Значение по умолчанию — "1.day". Другие способы указать значение см. в разделе gc.pruneExpire.

Запуск git pack-refs в репозитории делает его недоступным для клонирования версиями Git до 1.5.1.2 через простые транспортные протоколы, например HTTP. Эта переменная определяет, запускает ли git gc команду git pack-refs. Для включения этой функции во всех репозиториях, не являющихся чистыми, можно задать значение notbare либо указать логическое значение. По умолчанию используется true.

Хранить недостижимые объекты в cruft-пакете (см. git-repack[1]), а не в виде неупакованных объектов. Значение по умолчанию — true.

Ограничивает размер новых cruft-пакетов при перепаковке. Если задан одновременно с --max-cruft-size, приоритет имеет параметр командной строки. См. параметр --max-cruft-size команды git-repack[1].

При запуске git gc будет вызвана команда prune --expire 2.weeks.ago (а при использовании cruft-пакетов через gc.cruftPacks или --cruft — также repack --cruft --cruft-expiration 2.weeks.ago). Эту переменную конфигурации можно использовать для переопределения периода ожидания. Значение "now" отключает период ожидания и немедленно удаляет недостижимые объекты, а значение "never" запрещает удаление. Эта функция помогает предотвратить повреждение данных, если git gc выполняется одновременно с другим процессом, записывающим данные в репозиторий; см. раздел "NOTES" в git-gc[1].

При запуске git gc вызывается git worktree prune --expire 3.months.ago. С помощью этой переменной конфигурации можно задать другой период ожидания. Значение "now" отключает период ожидания и немедленно удаляет $GIT_DIR/worktrees, а значение "never" запрещает удаление.

git reflog expire удаляет записи reflog, возраст которых превышает это значение; по умолчанию — 90 дней. Значение "now" немедленно удаляет все записи, а значение "never" полностью запрещает их удаление по сроку давности. Если в середине имени указано "<pattern>" (например, "refs/stash"), настройка применяется только к ссылкам, соответствующим шаблону <pattern>.

git reflog expire удаляет записи reflog, возраст которых превышает это значение и которые недостижимы из текущей вершины; по умолчанию — 30 дней. Значение "now" немедленно удаляет все записи, а значение "never" полностью запрещает их удаление по сроку давности. Если в середине имени указано "<pattern>" (например, "refs/stash"), настройка применяется только к ссылкам, соответствующим шаблону <pattern>.

Такие записи обычно создаются при использовании git commit --amend или git rebase и относятся к коммитам, существовавшим до изменения коммита или перебазирования. Поскольку эти изменения не входят в текущий проект, большинство пользователей захотят удалять такие записи раньше, поэтому срок по умолчанию меньше, чем для gc.reflogExpire.

При принятии решения об удалении объекта (при создании cruft-пакета или хранении недостижимых объектов в неупакованном виде) выполняет указанные команды командной оболочки. Их вывод интерпретируется как идентификаторы объектов, которые Git будет считать «недавно созданными» независимо от их возраста. Считая время изменения этих объектов равным текущему, Git сохранит все упомянутые в выводе объекты и их потомков вне зависимости от их фактического возраста.

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

При перепаковке использовать указанный фильтр для перемещения определённых объектов в отдельный файл пакета. См. параметр --filter=<filter-spec> команды git-repack[1].

При перепаковке с использованием фильтра, см. gc.repackFilter, указанное расположение используется для создания файла пакета, содержащего отфильтрованные объекты. ПРЕДУПРЕЖДЕНИЕ: указанное расположение должно быть доступно, например, через механизм alternates в Git; в противном случае Git может счесть репозиторий повреждённым, поскольку не сможет получить доступ к объектам в этом файле пакета. См. параметр --filter-to=<dir> команды git-repack[1] и раздел objects/info/alternates справки gitrepository-layout[5].

Записи о конфликтах слияния, которые вы разрешили ранее, хранятся в течение указанного количества дней после запуска git rerere gc. Можно также использовать более понятные человеку значения, например "1.month.ago". Значение по умолчанию — 60 дней. См. git-rerere[1].

Записи о конфликтах слияния, которые вы не разрешили, хранятся в течение указанного количества дней после запуска git rerere gc. Можно также использовать более понятные человеку значения, например "1.month.ago". Значение по умолчанию — 15 дней. См. git-rerere[1].

Добавляет эту строку к каждому сообщению коммита. Чтобы отключить эту функцию, задайте пустую строку. По умолчанию — "via git-CVS emulator".

Определяет, включён ли интерфейс сервера CVS для этого репозитория. См. git-cvsserver[1].

Путь к файлу журнала, в который интерфейс сервера CVS, ну… записывает разные данные. См. git-cvsserver[1].

Если задано значение true, сервер проверяет атрибуты преобразования окончаний строк файлов, чтобы определить используемые режимы -k. Если атрибуты указывают Git считать файл текстовым, режим -k останется пустым, чтобы клиенты CVS считали его текстовым. Если атрибуты отключают преобразование текста, файлу будет назначен режим -kb, который запрещает клиенту выполнять какое-либо преобразование символов новой строки. Если атрибуты не позволяют определить тип файла, используется gitcvs.allBinary. См. gitattributes[5].

Используется, если gitcvs.usecrlfattr не определяет правильный режим -kb. Если задано значение true, все файлы, для которых не удалось определить режим, отправляются клиенту в режиме -kb. В результате клиент считает их двоичными файлами и не выполняет преобразование символов новой строки. Если задать значение "guess", содержимое файлов анализируется, чтобы определить, являются ли они двоичными, как и в случае с core.autocrlf.

База данных, используемая git-cvsserver для кэширования сведений о ревизиях, полученных из репозитория Git. Точное значение зависит от используемого драйвера базы данных; для SQLite (драйвера по умолчанию) это имя файла. Поддерживает подстановку переменных (подробности см. в git-cvsserver[1]). Не может содержать точку с запятой (;). По умолчанию: %Ggitcvs.%m.sqlite

Используемый драйвер Perl DBI. Здесь можно указать любой доступный драйвер, но он может не работать. git-cvsserver тестируется с DBD::SQLite, сообщалось о работоспособности с DBD::Pg и о неработоспособности с DBD::mysql. Экспериментальная функция. Не может содержать двойное двоеточие (:). По умолчанию: SQLite. См. git-cvsserver[1].

Имя пользователя и пароль для базы данных. Полезно только при настройке gitcvs.dbDriver, поскольку SQLite не использует понятия пользователей и паролей баз данных. gitcvs.dbUser поддерживает подстановку переменных (подробности см. в git-cvsserver[1]).

Префикс имени таблиц базы данных. Добавляется в начало имён всех используемых таблиц, позволяя использовать одну базу данных для нескольких репозиториев. Поддерживает подстановку переменных (подробности см. в git-cvsserver[1]). Все небуквенные символы заменяются символами подчёркивания.

Описание см. в gitweb[1].

Описание см. в gitweb.conf[5].

Путь к программе, используемой вместо "gpg" при создании или проверке подписи PGP. Программа должна поддерживать тот же интерфейс командной строки, что и GPG: для проверки отсоединённой подписи выполняется команда "gpg --verify $signature - <$file", и программа должна сообщать об успешной проверке подписи, завершая работу с кодом 0. Для создания отсоединённой подписи в формате ASCII-armored содержимое, которое нужно подписать, передаётся стандартному вводу команды "gpg -bsau $key", а программа должна отправить результат в стандартный вывод.

Задаёт формат ключа, используемый для подписания с помощью --gpg-sign. По умолчанию используется "openpgp". Другие возможные значения: "x509", "ssh".

Описание формата подписи, который зависит от выбранного gpg.format, см. в gitformat-signature[5].

Используйте этот параметр, чтобы настроить программу для выбранного формата подписи (см. gpg.program и gpg.format). gpg.program по-прежнему можно использовать как устаревший синоним для gpg.openpgp.program. По умолчанию для gpg.x509.program используется "gpgsm", а для gpg.ssh.program — "ssh-keygen".

Задаёт минимальный уровень доверия для проверки подписи. Если этот параметр не задан, для проверки подписей при операциях слияния требуется ключ с уровнем доверия не ниже marginal. Для других операций, выполняющих проверку подписи, требуется ключ с уровнем доверия не ниже undefined. Задание этого параметра переопределяет требуемый уровень доверия для всех операций. Поддерживаемые значения в порядке возрастания значимости:

Эта команда будет выполнена, если user.signingkey не задан, а запрошена подпись SSH. При успешном завершении в первой строке вывода ожидается корректный открытый ключ SSH с префиксом key::. Это позволяет использовать скрипт для динамического поиска нужного открытого ключа, когда статически настроить user.signingKey нецелесообразно. Например, когда ключи или SSH-сертификаты часто меняются или выбор нужного ключа зависит от внешних факторов, неизвестных Git.

Файл, содержащий открытые ключи SSH, которым вы готовы доверять. Файл состоит из одной или нескольких строк с субъектами, за которыми следует открытый ключ SSH. Например: user1@example.com,user2@example.com ssh-rsa AAAAX1... Подробности см. в разделе "ALLOWED SIGNERS" справки ssh-keygen(1). Субъект используется только для идентификации ключа и доступен при проверке подписи.

В SSH, в отличие от gpg, нет понятия уровней доверия. Чтобы различать действительные и доверенные подписи, при проверке подписи устанавливается уровень доверия fully, если открытый ключ присутствует в allowedSignersFile. В противном случае уровень доверия равен undefined, и git verify-commit/tag завершится с ошибкой.

Этот файл можно разместить вне репозитория; каждый разработчик поддерживает собственное хранилище доверенных ключей. Центральный сервер репозитория может автоматически создавать этот файл из SSH-ключей, имеющих доступ на отправку изменений, чтобы проверять код. В корпоративной среде этот файл, вероятно, создаётся в общей папке средствами автоматизации, которые уже управляют SSH-ключами разработчиков.

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

Начиная с OpensSSH 8.8 в этом файле можно указывать срок действия ключа с помощью параметров valid-after и valid-before. Git будет считать подписи действительными, если подписывающий ключ был действителен на момент создания подписи. Это позволяет пользователям сменить ключ для подписания, не делая недействительными все ранее созданные подписи.

Также можно использовать ключ SSH CA с параметром cert-authority (см. раздел "CERTIFICATES" справки ssh-keygen(1)).

Файл SSH KRL или список отозванных открытых ключей (без префикса субъекта). Подробности см. в справке ssh-keygen(1). Если открытый ключ найден в этом файле, ему всегда будет присвоен уровень доверия "never", а подписи будут считаться недействительными.

Если задано значение true, по умолчанию включается параметр -n.

Если задано значение true, по умолчанию включается параметр --column.

Задаёт поведение сопоставления по умолчанию. Значение basic, extended, fixed или perl включает соответственно параметр --basic-regexp, --extended-regexp, --fixed-strings или --perl-regexp, а значение default использует параметр grep.extendedRegexp, чтобы выбрать между basic и extended.

Если задано значение true, по умолчанию включается параметр --extended-regexp. Этот параметр игнорируется, если для параметра grep.patternType задано значение, отличное от default.

Количество рабочих потоков grep. Если значение не задано (или равно 0), Git использует столько потоков, сколько доступно логических ядер.

Если задано значение true, по умолчанию включается параметр --full-name.

Если задано значение true, вместо этого используется git grep --no-index, если команда git grep выполняется вне репозитория git. По умолчанию — false.

Задаёт ширину окна сообщения коммита в git-gui[1]. По умолчанию используется значение "75".

Задаёт количество контекстных строк, используемых в вызовах diff из git-gui[1]. По умолчанию используется значение "5".

Определяет, отображает ли git-gui[1] неотслеживаемые файлы в списке файлов. По умолчанию используется значение "true".

Задаёт кодировку символов по умолчанию для отображения содержимого файлов в git-gui[1] и gitk[1]. Её можно переопределить, задав атрибут encoding для соответствующих файлов (см. gitattributes[5]). Если этот параметр не задан, инструменты используют кодировку локали.

Определяет, должны ли новые ветки, созданные с помощью git-gui[1], по умолчанию отслеживать удалённые ветки с совпадающими именами. По умолчанию: "false".

Используется как предлагаемое имя при создании новых веток с помощью git-gui[1].

Значение "true" указывает, что git-gui[1] должен удалять ветки удалённого отслеживания при выполнении fetch. По умолчанию используется значение "false".

Определяет, должен ли git-gui[1] доверять временным меткам изменения файлов. По умолчанию временным меткам не доверяют.

Задаёт словарь для проверки орфографии сообщений коммитов в git-gui[1]. Если задано значение "none", проверка орфографии отключается.

Если задано значение true, git gui blame использует -C вместо -C -C для определения исходного расположения. Это значительно ускоряет blame в больших репозиториях за счёт менее тщательного обнаружения копирования.

Задаёт порог для определения исходного расположения в git gui blame, измеряемый количеством буквенно-цифровых символов. Дополнительные сведения об обнаружении копирования см. в руководстве git-blame[1].

Задаёт радиус исторического контекста в днях, отображаемого в gitk[1] для выбранного коммита при выборе пункта меню Show History Context в git gui blame. Если значение этой переменной равно нулю, отображается вся история.

Определяет, должен ли git-gui[1] предлагать выполнить сборку мусора, если Git обнаруживает в репозитории большое количество свободных объектов. По умолчанию используется значение "true".

Задаёт командную строку оболочки, выполняемую при выборе соответствующего пункта меню Tools в git-gui[1]. Этот параметр обязателен для каждого инструмента. Команда выполняется из корневого каталога рабочего дерева; в окружение передаётся имя инструмента в переменной GIT_GUITOOL, имя выбранного файла — в FILENAME, а имя текущей ветки — в CUR_BRANCH (если HEAD отделён, CUR_BRANCH имеет пустое значение).

Запускать инструмент, только если в графическом интерфейсе выбран diff. Гарантирует, что FILENAME не пуст.

Запускать команду без вывода, не создавая окна для отображения результата.

Не сканировать рабочий каталог на наличие изменений после завершения работы инструмента.

Показывать диалог подтверждения перед запуском инструмента.

Запрашивать у пользователя строковый аргумент и передавать его инструменту через переменную окружения ARGS. Поскольку запрос аргумента подразумевает подтверждение, параметр confirm не действует, если этот параметр включён. Если для параметра задано значение true, yes или 1, в диалоговом окне используется встроенная общая подсказка; в противном случае используется точное значение переменной.

Запрашивать у пользователя одну допустимую ревизию и задавать переменную окружения REVISION. В остальном этот параметр аналогичен argPrompt и может использоваться вместе с ним.

Показывать только несведённые ветки во вложенном диалоговом окне revPrompt. Это полезно для инструментов, подобных merge или rebase, но не для таких операций, как checkout или reset.

Задаёт заголовок диалогового окна запроса. По умолчанию используется имя инструмента.

Задаёт общую строку подсказки, отображаемую в верхней части диалогового окна перед разделами для argPrompt и revPrompt. По умолчанию в строке указывается фактическая команда.

Задаёт браузер, используемый для отображения справки в формате web. См. git-help[1].

Переопределяет формат справки, используемый по умолчанию командой git-help[1]. Поддерживаются значения man, info, web и html. По умолчанию используется man. Значения web и html означают одно и то же.

Если Git обнаруживает опечатку и может определить ровно одну допустимую команду, похожую на ошибочно введённую, он попытается предложить правильную команду или даже автоматически выполнить её. Возможные значения параметра конфигурации:

Задаёт путь к каталогу с документацией HTML. Поддерживаются пути файловой системы и URL. При отображении справки в формате web этот путь добавляется в начало URL HTML-страниц. По умолчанию используется путь к документации в каталоге установки Git.

Команда, выполняемая для hook.<friendly-name>. <friendly-name> — уникальное имя, идентифицирующее этот хук. События хуков, запускающие команду, настраиваются с помощью hook.<friendly-name>.event. Значением может быть путь к исполняемому файлу или однострочная команда оболочки. Если для одного и того же <friendly-name> указано несколько значений, используется только последнее разобранное значение. См. git-hook[1].

События хуков, запускающие hook.<friendly-name>. Значение — имя события хука, например «pre-commit» или «update». (Полный список событий хуков см. в githooks[5].) При наступлении указанного события выполняется связанный с ним hook.<friendly-name>.command. Этот ключ может иметь несколько значений. Чтобы запускать hook.<friendly-name> при нескольких событиях, укажите этот ключ несколько раз. Пустое значение сбрасывает список событий, удаляя все ранее заданные события для hook.<friendly-name>. См. git-hook[1].

<friendly-name> не должно совпадать с именем известного события хука (например, не используйте hook.pre-commit.event). Использование известного имени события в качестве friendly-name приводит к фатальной ошибке, поскольку создаёт неоднозначность с hook.<event>.enabled и hook.<event>.jobs. Для неизвестных имён событий выводится предупреждение, если <friendly-name> совпадает со значением события.

Определяет, включён ли хук hook.<friendly-name>. По умолчанию — true. Установите значение false, чтобы отключить хук, не удаляя его настройки. Это особенно полезно, когда хук задан в системном или глобальном файле конфигурации и его нужно отключить для определённого репозитория. См. git-hook[1].

Определяет, может ли хук hook.<friendly-name> выполняться параллельно с другими хуками для того же события. По умолчанию — false. Установите значение true только в том случае, если скрипт хука безопасно выполнять параллельно с другими хуками для того же события. Если для какого-либо хука события значение этого параметра не равно true, все хуки этого события выполняются последовательно независимо от значения hook.jobs. Этот параметр нужно указывать только для настроенных (именованных) хуков. Для традиционных хуков, находящихся в каталоге hooks, указывать его не нужно: они выполняются параллельно, если эффективное число заданий больше 1. См. git-hook[1].

Параметр, включающий или отключающий все хуки для события хука <event>. Если установить значение false, для этого события не будут запускаться никакие хуки независимо от настроек отдельных хуков hook.<friendly-name>.enabled. По умолчанию — true. См. git-hook[1].

Примечание об именовании: <event> должно быть именем события (например, pre-commit), а не friendly-name хука. Поскольку использовать известное имя события в качестве friendly-name запрещено (см. приведённый выше раздел hook.<friendly-name>.event), для известных событий неоднозначности между настройками .enabled на уровне события и отдельного хука нет. Для неизвестных событий, если friendly-name совпадает с именем события вопреки предупреждению, параметр .enabled рассматривается только как настройка отдельного хука.

Задаёт, сколько хуков может одновременно выполняться для события хука <event> (например, hook.post-receive.jobs = 4). Переопределяет hook.jobs для этого события. Действуют те же ограничения параллельного выполнения: этот параметр не влияет на работу, если для всех настроенных хуков этого события не задано значение hook.<friendly-name>.parallel равным true. Установите значение -1, чтобы использовать число доступных ядер ЦП. Значением должно быть положительное целое число или -1; нулевое значение отклоняется с предупреждением. См. git-hook[1].

Примечание об именовании: хотя этот ключ похож на hook.<friendly-name>.* (настройку отдельного хука), <event> должно быть именем события, а не friendly-name хука. Компонент ключа сохраняется буквально и во время выполнения ищется по имени события; преобразования между этими двумя пространствами имён не происходит. Например, ключ вида hook.my-hook.jobs сохраняется как "my-hook", но во время выполнения поиск выполняется по имени события (например, "post-receive"), поэтому hook.my-hook.jobs будет молча проигнорирован, даже если для этого события зарегистрирован my-hook. При настройке hook.<event>.jobs используйте hook.post-receive.jobs или любое другое допустимое имя события.

Задаёт, сколько хуков может одновременно выполняться при параллельном запуске хуков. Если параметр не задан, по умолчанию используется значение 1 (последовательное выполнение). Установите значение -1, чтобы использовать число доступных ядер ЦП. Значение можно переопределить для отдельного события с помощью hook.<event>.jobs. Некоторые хуки всегда выполняются последовательно независимо от этого параметра, поскольку они работают с общими данными и их нельзя безопасно выполнять параллельно:

Этот параметр не влияет на работу, если для всех настроенных хуков этого события не задано значение hook.<friendly-name>.parallel равным true.

Для хуков pre-push, которые обычно не объединяют stdout и stderr, установка значения больше 1 (или передача -j) приведёт к перенаправлению stdout в stderr, чтобы обеспечить корректное разделение перемежающегося параллельного вывода.

Переопределяет HTTP-прокси, обычно задаваемый с помощью переменных среды http_proxy, https_proxy и all_proxy (см. curl(1)). Помимо синтаксиса, понимаемого curl, можно указать строку прокси с именем пользователя, но без пароля. В этом случае git попытается получить пароль тем же способом, что и для других учётных данных. Дополнительные сведения см. в gitcredentials[7]. Таким образом, синтаксис имеет вид [protocol://][user[:password]@]proxyhost[:port][/path]. Этот параметр можно переопределить отдельно для каждого удалённого репозитория; см. remote.<name>.proxy

Любой прокси, независимо от способа настройки, должен быть полностью прозрачным и не должен каким-либо образом изменять, преобразовывать или буферизовать запрос или ответ. Известно, что непрозрачные прокси вызывают различные сбои в работе Git.

Задаёт метод аутентификации на HTTP-прокси. Параметр действует, только если настроенная строка прокси содержит имя пользователя (то есть имеет вид user@host или user@host:port). Значение можно переопределить отдельно для каждого удалённого репозитория; см. remote.<name>.proxyAuthMethod. Оба параметра можно переопределить с помощью переменной среды GIT_HTTP_PROXY_AUTHMETHOD. Возможные значения:

Путь к файлу с клиентским сертификатом, используемым для аутентификации на HTTPS-прокси. Значение можно переопределить с помощью переменной среды GIT_PROXY_SSL_CERT.

Путь к файлу с закрытым ключом, используемым для аутентификации на HTTPS-прокси. Значение можно переопределить с помощью переменной среды GIT_PROXY_SSL_KEY.

Включает запрос пароля Git для SSL-сертификата прокси. В противном случае OpenSSL будет запрашивать пароль у пользователя, возможно, неоднократно, если сертификат или закрытый ключ зашифрован. Значение можно переопределить с помощью переменной среды GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED.

Путь к файлу со связкой сертификатов, используемой для проверки прокси при работе через HTTPS-прокси. Значение можно переопределить с помощью переменной среды GIT_PROXY_SSL_CAINFO.

Пытается выполнить аутентификацию, не запрашивая имя пользователя или пароль. Это можно использовать для попытки аутентификации GSS-Negotiate без указания имени пользователя в URL, поскольку libcurl обычно требует имя пользователя для аутентификации. Возможные значения:

Пытается выполнить аутентификацию, не отправляя предварительно запрос без аутентификации и не дожидаясь ответа 401. Это можно использовать, чтобы гарантировать аутентификацию всех запросов. Если для http.emptyAuth задано значение true, этот параметр не действует.

Если используемый помощник учётных данных указывает схему аутентификации (то есть через поле authtype), будет использоваться эта схема; если указаны имя пользователя и пароль без схемы, используется базовая аутентификация. Значение параметра определяет схему, запрашиваемую у помощника. Возможные значения:

Обратите внимание, что при такой настройке всегда следует использовать TLS, поскольку в противном случае легко случайно раскрыть учётные данные в открытом виде, если выбрана базовая аутентификация.

Управляет делегированием учётных данных GSSAPI. В libcurl делегирование по умолчанию отключено начиная с версии 7.21.7. Задаёт параметр, указывающий серверу, что ему разрешено делегировать в отношении учётных данных пользователя. Используется с GSS/Kerberos. Возможные значения:

Передаёт дополнительный HTTP-заголовок при взаимодействии с сервером. Если задано несколько таких записей, все они добавляются в качестве дополнительных заголовков. Чтобы разрешить переопределение настроек, унаследованных из системной конфигурации, пустое значение сбрасывает список дополнительных заголовков.

Путь к файлу с ранее сохранёнными строками cookie, которые следует использовать в HTTP-сеансе Git, если они подходят для сервера. Формат файла с cookie должен соответствовать обычным HTTP-заголовкам или формату файлов cookie Netscape/Mozilla (см. curl(1)). Если задать пустую строку, будут приниматься только новые cookie от сервера и отправляться обратно в последующих запросах в рамках того же соединения. Обратите внимание: файл, указанный в http.cookieFile, используется только для чтения, если не задан параметр http.saveCookies.

Если параметр задан, сохраняет в файл, указанный в http.cookieFile, cookie, полученные во время запросов. Не действует, если параметр http.cookieFile не задан или задан как пустая строка.

Использует указанную версию протокола HTTP при взаимодействии с сервером. Если требуется принудительно задать версию по умолчанию, доступная версия и версия по умолчанию зависят от libcurl. В настоящее время этот параметр может принимать следующие значения:

Информация о разрешении имён узлов, которая будет использоваться libcurl в первую очередь при отправке HTTP-запросов. Информация должна иметь один из следующих форматов:

Первый формат перенаправляет все запросы к указанному HOST:PORT на заданные ADDRESS(s). Второй формат удаляет все предыдущие значения конфигурации для этой комбинации HOST:PORT. Чтобы упростить переопределение всех настроек, унаследованных из системной конфигурации, пустое значение сбрасывает всю информацию о разрешении имён в пустой список.

Версия SSL, используемая при согласовании SSL-соединения, если требуется принудительно задать версию по умолчанию. Доступные версии и версия по умолчанию зависят от того, была ли libcurl собрана с NSS или OpenSSL, а также от конкретной конфигурации используемой криптографической библиотеки. Внутри этот параметр задаёт опцию CURLOPT_SSL_VERSION; дополнительные сведения о формате этой опции и поддерживаемых версиях SSL см. в документации libcurl. В настоящее время этот параметр может принимать следующие значения:

Значение можно переопределить с помощью переменной среды GIT_SSL_VERSION. Чтобы заставить git использовать версию SSL по умолчанию для libcurl и игнорировать явно заданный параметр http.sslversion, задайте для GIT_SSL_VERSION пустую строку.

Список шифров SSL, используемых при согласовании SSL-соединения. Доступные шифры зависят от того, была ли libcurl собрана с NSS или OpenSSL, а также от конкретной конфигурации используемой криптографической библиотеки. Внутри этот параметр задаёт опцию CURLOPT_SSL_CIPHER_LIST; дополнительные сведения о формате этого списка см. в документации libcurl.

Значение можно переопределить с помощью переменной среды GIT_SSL_CIPHER_LIST. Чтобы заставить git использовать список шифров libcurl по умолчанию и игнорировать явно заданный параметр http.sslCipherList, задайте для GIT_SSL_CIPHER_LIST пустую строку.

Определяет, проверять ли сертификат SSL при получении или отправке данных через HTTPS. По умолчанию — true. Значение можно переопределить с помощью переменной среды GIT_SSL_NO_VERIFY.

Файл с сертификатом SSL, используемым при получении или отправке данных через HTTPS. Значение можно переопределить с помощью переменной среды GIT_SSL_CERT.

Файл с закрытым ключом SSL, используемым при получении или отправке данных через HTTPS. Значение можно переопределить с помощью переменной среды GIT_SSL_KEY.

Включает запрос пароля Git для сертификата SSL. В противном случае OpenSSL будет запрашивать пароль у пользователя, возможно, неоднократно, если сертификат или закрытый ключ зашифрован. Значение можно переопределить с помощью переменной среды GIT_SSL_CERT_PASSWORD_PROTECTED.

Файл с сертификатами, используемыми для проверки другой стороны при получении или отправке данных через HTTPS. Значение можно переопределить с помощью переменной среды GIT_SSL_CAINFO.

Каталог с файлами сертификатов ЦС, используемыми для проверки другой стороны при получении или отправке данных через HTTPS. Значение можно переопределить с помощью переменной среды GIT_SSL_CAPATH.

Имя используемой серверной части SSL (например, «openssl» или «schannel»). Этот параметр игнорируется, если cURL не поддерживает выбор серверной части SSL во время выполнения.

Тип клиентского сертификата, используемого при получении или отправке данных через HTTPS. При использовании серверных частей openssl или gnutls поддерживаются значения «PEM» и «DER». Значение «P12» поддерживается для «openssl», «schannel», «securetransport» и gnutls версии 8.11 и выше. См. также CURLOPT_SSLCERTTYPE в документации libcurl. Значение можно переопределить с помощью переменной среды GIT_SSL_CERT_TYPE.

Тип закрытого ключа клиента, используемого при получении или отправке данных через HTTPS (например, «PEM», «DER» или «ENG»). Применяется только при использовании серверной части «openssl». Значение «DER» не поддерживается в openssl. Особенно полезно значение «ENG» для аутентификации с помощью токенов PKCS#11, если в параметре sslCert указан URL PKCS#11. См. также CURLOPT_SSLKEYTYPE в документации libcurl. Значение можно переопределить с помощью переменной среды GIT_SSL_KEY_TYPE.

Используется для включения или отключения проверки отзыва сертификатов в cURL, когда для http.sslBackend задано значение «schannel». Если параметр не задан, по умолчанию используется true. Отключать эту проверку следует только в том случае, если Git постоянно выдаёт ошибку о проверке статуса отзыва сертификата. Этот параметр игнорируется, если cURL не поддерживает установку соответствующей опции SSL во время выполнения.

Начиная с cURL v7.60.0, серверная часть Secure Channel может использовать связку сертификатов, заданную через http.sslCAInfo, однако при этом будет переопределено хранилище сертификатов Windows. Поскольку по умолчанию это нежелательно, Git по умолчанию сообщает cURL не использовать эту связку, если серверная часть schannel настроена через http.sslBackend, если только параметр http.schannelUseSSLCAInfo не переопределяет это поведение.

Открытый ключ службы https. Значением может быть имя файла с открытым ключом в формате PEM или DER либо строка, начинающаяся с sha256//, за которым следует хеш sha256 открытого ключа в кодировке base64. См. также CURLOPT_PINNEDPUBLICKEY в документации libcurl. git завершится с ошибкой, если этот параметр задан, но не поддерживается cURL.

Пытается использовать AUTH SSL/TLS и шифрованную передачу данных при подключении через обычный протокол FTP. Это может потребоваться, если FTP-сервер требует этого по соображениям безопасности или если вы хотите устанавливать защищённое соединение всякий раз, когда удалённый FTP-сервер его поддерживает. По умолчанию — false, поскольку на неправильно настроенных серверах это может приводить к ошибкам проверки сертификата.

Количество HTTP-запросов, запускаемых параллельно. Значение можно переопределить с помощью переменной среды GIT_HTTP_MAX_REQUESTS. По умолчанию — 5.

Количество сеансов curl (суммарно по слотам), сохраняемых между запросами. Они не будут завершены вызовом curl_easy_cleanup(), пока не будет вызвана функция http_cleanup(). Если USE_CURL_MULTI не определён, значение будет ограничено единицей. По умолчанию — 1.

Максимальный размер буфера в байтах, используемого интеллектуальными транспортами HTTP при отправке данных POST на удалённую систему. Для запросов, превышающих размер этого буфера, используется HTTP/1.1 и Transfer-Encoding: chunked, чтобы не создавать локально огромный файл pack. По умолчанию — 1 MiB, чего достаточно для большинства запросов.

Обратите внимание: увеличение этого ограничения эффективно только для отключения передачи с разбиением на блоки, поэтому его следует использовать лишь в случаях, когда удалённый сервер или прокси поддерживает только HTTP/1.0 либо не соответствует стандарту HTTP. Как правило, увеличение значения не является эффективным решением большинства проблем с отправкой данных, но может значительно повысить потребление памяти, поскольку весь буфер выделяется даже для небольших отправок.

Если скорость передачи HTTP в байтах в секунду остаётся ниже http.lowSpeedLimit дольше http.lowSpeedTime секунд, передача прерывается. Значения можно переопределить с помощью переменных среды GIT_HTTP_LOW_SPEED_LIMIT и GIT_HTTP_LOW_SPEED_TIME.

Задаёт, сколько секунд ждать в неактивном соединении перед отправкой проб TCP keepalive (если это поддерживается ОС). Если параметр не задан, используется значение curl по умолчанию. Значение можно переопределить с помощью переменной среды GIT_HTTP_KEEPALIVE_IDLE.

Задаёт интервал в секундах между пробами TCP keepalive (если это поддерживается ОС). Если параметр не задан, используется значение curl по умолчанию. Значение можно переопределить с помощью переменной среды GIT_HTTP_KEEPALIVE_INTERVAL.

Задаёт количество проб TCP keepalive, отправляемых до прекращения попыток и завершения соединения (если это поддерживается ОС). Если параметр не задан, используется значение curl по умолчанию. Значение можно переопределить с помощью переменной среды GIT_HTTP_KEEPALIVE_COUNT.

Время ожидания в секундах перед повторной попыткой, если сервер возвращает HTTP 429 (слишком много запросов) без заголовка Retry-After. По умолчанию — 0 (повторная попытка выполняется немедленно). Если заголовок Retry-After присутствует, его значение имеет приоритет над этим параметром; однако для автоматического использования предоставленного сервером заголовка Retry-After требуется libcurl версии 7.66.0 или новее. В более старых версиях настройте этот параметр вручную, чтобы задать задержку перед повторной попыткой. Значение можно переопределить с помощью переменной среды GIT_HTTP_RETRY_AFTER. См. также http.maxRetries и http.maxRetryTime.

Максимальное количество повторных попыток после получения ответа HTTP 429 (слишком много запросов). Чтобы отключить повторные попытки, установите значение 0 (по умолчанию). Значение можно переопределить с помощью переменной среды GIT_HTTP_MAX_RETRIES. См. также http.retryAfter и http.maxRetryTime.

Максимальное время в секундах ожидания одной повторной попытки при обработке ответов HTTP 429 (Too Many Requests). Если сервер запрашивает задержку (через заголовок Retry-After) или если http.retryAfter настроен на значение, превышающее этот максимум, Git немедленно завершит работу, не дожидаясь окончания задержки. Значение по умолчанию — 300 секунд (5 минут). Можно переопределить с помощью переменной окружения GIT_HTTP_MAX_RETRY_TIME. См. также http.retryAfter и http.maxRetries.

Логическое значение, отключающее использование команды FTP EPSV в curl. Это может быть полезно при работе с некоторыми «некачественными» FTP-серверами, не поддерживающими режим EPSV. Можно переопределить с помощью переменной окружения GIT_CURL_FTP_NO_EPSV. Значение по умолчанию — false (curl будет использовать EPSV).

Строка HTTP USER_AGENT, передаваемая HTTP-серверу. Значение по умолчанию соответствует версии клиента Git, например git/1.7.1. Этот параметр позволяет заменить это значение более распространённым, например Mozilla/4.0. Это может потребоваться, например, при подключении через межсетевой экран, который разрешает HTTP-соединения только с набором распространённых строк USER_AGENT (но не с такими, как git/1.7.1). Можно переопределить с помощью переменной окружения GIT_HTTP_USER_AGENT.

Следует ли Git переходить по HTTP-перенаправлениям. Если задано значение true, Git будет автоматически переходить по всем перенаправлениям, полученным от сервера. Если задано значение false, Git будет считать все перенаправления ошибками. Если задано значение initial, Git будет переходить по перенаправлениям только для первоначального запроса к удалённому репозиторию, но не для последующих HTTP-запросов. Поскольку Git использует перенаправленный URL как базовый для последующих запросов, этого обычно достаточно. Значение по умолчанию — initial.

Любой из приведённых выше параметров http.* можно применять выборочно к некоторым URL. Чтобы ключ конфигурации соответствовал URL, каждый элемент ключа конфигурации сравнивается с соответствующим элементом URL в следующем порядке:

Приведённый выше список упорядочен по убыванию приоритета; URL, соответствующий пути ключа конфигурации, предпочтительнее URL, соответствующего имени пользователя. Например, если URL — https://user@example.com/foo/bar, совпадение с ключом конфигурации https://example.com/foo будет предпочтительнее совпадения с ключом конфигурации https://user@example.com.

Перед сравнением все URL нормализуются (часть URL с паролем, если она есть, всегда игнорируется при сравнении), чтобы эквивалентные URL, записанные по-разному, корректно совпадали. Настройки переменных окружения всегда переопределяют любые совпадения. Для сравнения используются URL, непосредственно переданные командам Git. Это означает, что URL, посещённые в результате перенаправления, не участвуют в сравнении.

Кодировка символов, в которой хранятся сообщения коммитов; сам Git, в сущности, не зависит от неё, но эта информация необходима, например, при импорте коммитов из электронных писем или в графическом браузере истории gitk (а возможно, в будущем и в других местах или других пользовательских интерфейсах). См., например, git-mailinfo[1]. По умолчанию — utf-8.

Кодировка символов, в которую преобразуются сообщения коммитов при выполнении git log и подобных команд.

Папка, в которую помещаются письма, обычно папка Drafts. Например: INBOX.Drafts, INBOX/Drafts или [Gmail]/Drafts. Папка IMAP, с которой необходимо взаимодействовать, ДОЛЖНА быть указана; значение этой переменной конфигурации используется как значение по умолчанию, если параметр --folder не задан.

Команда для настройки туннеля к серверу IMAP, через который будут передаваться команды вместо прямого сетевого подключения к серверу. Обязательна, если не задан параметр imap.host.

URL, указывающий на сервер. Для незащищённых соединений используйте префикс imap://, а для защищённых — префикс imaps://. Игнорируется, если задан параметр imap.tunnel, в противном случае обязателен.

Имя пользователя для входа на сервер.

Пароль для входа на сервер.

Целочисленный номер порта сервера, к которому следует подключиться. По умолчанию — 143 для узлов imap:// и 993 для узлов imaps://. Игнорируется, если задан параметр imap.tunnel.

Логическое значение, включающее или отключающее проверку сертификата сервера, используемого SSL/TLS-соединением. По умолчанию — true. Игнорируется, если задан параметр imap.tunnel.

Логическое значение, включающее или отключающее использование HTML-кодирования при отправке патча. Патч в HTML-кодировке будет заключён в <pre> и будет иметь тип содержимого text/html. Ирония в том, что включение этого параметра заставляет Thunderbird отправлять патч как обычное текстовое письмо с форматом fixed. По умолчанию — false.

Задаёт метод аутентификации на сервере IMAP. Если Git собран с параметром NO_CURL, версия curl старше 7.34.0 или вы запускаете git-imap-send с параметром --no-curl, поддерживаются только методы PLAIN, CRAM-MD5, OAUTHBEARER и XOAUTH2. Если параметр не задан, git imap-send использует базовую команду IMAP LOGIN для передачи открытого текста.

Специальные переменные для подключения других файлов конфигурации. См. раздел «ФАЙЛ КОНФИГУРАЦИИ» в основной документации git-config[1], в частности подразделы «Подключение» и «Условное подключение».

Указывает, должен ли индексный файл содержать раздел «End Of Index Entry». Это сокращает время загрузки индекса на многопроцессорных машинах, но при чтении индекса в версиях Git до 2.20 выводится сообщение «ignoring EOIE extension». По умолчанию задаётся значение true, если index.threads включён явно, и false в противном случае.

Указывает, должен ли индексный файл содержать раздел «Index Entry Offset Table». Это сокращает время загрузки индекса на многопроцессорных машинах, но при чтении индекса в версиях Git до 2.20 выводится сообщение «ignoring IEOT extension». По умолчанию задаётся значение true, если index.threads включён явно, и false в противном случае.

Если параметр включён, индекс записывается с использованием записей разреженных каталогов. Это не действует, если параметры core.sparseCheckout и core.sparseCheckoutCone не включены одновременно. По умолчанию — false.

Указывает количество потоков, запускаемых при загрузке индекса. Это предназначено для сокращения времени загрузки индекса на многопроцессорных машинах. Значение 0 или true заставит Git автоматически определить число процессоров и соответственно задать количество потоков. Значение 1 или false отключит многопоточность. По умолчанию — true.

Задаёт версию, с которой следует инициализировать новые индексные файлы. На существующие репозитории это не влияет. Если включён параметр feature.manyFiles, значением по умолчанию будет 4.

Если параметр включён, завершающий хеш индексного файла не вычисляется. Это ускоряет команды Git, изменяющие индекс, например git add, git commit или git status. Вместо контрольной суммы в конец записывается последовательность нулевых байтов, указывающая на то, что вычисление было пропущено.

Если включить index.skipHash, клиенты Git старше версии 2.13.0 откажутся разбирать индекс, а клиенты Git старше версии 2.40.0 сообщат об ошибке при выполнении git fsck.

Укажите каталог, из которого будут копироваться шаблоны. (См. раздел «КАТАЛОГ ШАБЛОНОВ» в git-init[1].)

Позволяет переопределить имя ветки по умолчанию, например при инициализации нового репозитория.

Позволяет переопределить формат объектов по умолчанию для новых репозиториев. См. --object-format= в git-init[1]. Параметр командной строки и переменная среды GIT_DEFAULT_HASH имеют приоритет над этой настройкой.

Позволяет переопределить формат хранения ссылок по умолчанию для новых репозиториев. См. --ref-format= в git-init[1]. Параметр командной строки и переменная среды GIT_DEFAULT_REF_FORMAT имеют приоритет над этой настройкой.

Логическое значение, определяющее, должны ли git init и git clone автоматически устанавливать extensions.submodulePathConfig в значение true. Это позволяет автоматически использовать расширение пути подмодуля во всех новых репозиториях. Если значение не задано, по умолчанию используется false.

Укажите программу, которая будет использоваться для просмотра рабочего репозитория в gitweb. См. git-instaweb[1].

Команда HTTP-демона для запуска gitweb в рабочем репозитории. См. git-instaweb[1].

Если значение равно true, веб-сервер, запущенный командой git-instaweb[1], будет привязан к локальному IP-адресу (127.0.0.1).

Путь к каталогу модулей по умолчанию, который будет использовать git-instaweb[1] вместо /usr/lib/apache2/modules. Используется, только если httpd — это Apache.

Номер порта, к которому привязывается HTTP-демон gitweb. См. git-instaweb[1].

Если установлено значение true, интерактивные команды позволяют пользователю вводить один символ нажатием одной клавиши (то есть без нажатия Enter). Сейчас это используется в режиме --patch команд git-add[1], git-checkout[1], git-restore[1], git-commit[1], git-reset[1] и git-stash[1].

Когда интерактивная команда (например, git add --patch) показывает раскрашенный diff, Git передаёт его через команду оболочки, заданную этой переменной конфигурации. Команда может дополнительно форматировать diff для удобства чтения, если сохраняет взаимно-однозначное соответствие со строками исходного diff. По умолчанию отключено (фильтрация не выполняется).

Если значение равно true, команды git-log[1], git-show[1] и git-whatchanged[1] предполагают, что --abbrev-commit. Этот параметр можно переопределить с помощью --no-abbrev-commit.

Задаёт режим даты и времени по умолчанию для команды log. Установка значения для log.date аналогична использованию параметра git log --date. Подробности см. в git-log[1].

Если формат задан как «auto:foo» и используется пейджер, для даты будет применён формат «foo». В противном случае будет использоваться «default».

Выводит имена ссылок для всех коммитов, показываемых командой журнала. Возможные значения:

Это аналог параметра --decorate команды git log.

По умолчанию git log показывает декорации только для некоторых известных пространств имён ссылок. Если задано all, все ссылки отображаются как декорации.

Исключает указанные шаблоны из декораций журнала. Это аналог параметра командной строки --decorate-refs-exclude, но параметр конфигурации можно переопределить параметром --decorate-refs.

Задаёт формат diff, используемый при указании --diff-merges=on; подробности см. в --diff-merges в git-log[1]. По умолчанию используется separate.

Если значение равно true, git log будет вести себя так, как если бы был указан параметр --follow, когда задан один <path>. Это имеет те же ограничения, что и --follow: нельзя отслеживать несколько файлов, а также команда плохо работает с нелинейной историей.

Список цветов, разделённых запятыми, используемых для отображения линий истории в git log --graph.

Если значение равно true, начальный коммит будет показан как крупное событие создания. Это эквивалентно diff с пустым деревом. Такие инструменты, как git-log[1] и git-whatchanged[1], которые обычно скрывают корневой коммит, теперь будут показывать его. По умолчанию — true.

Если значение равно true, команды git-log[1], git-show[1] и git-whatchanged[1] предполагают, что --show-signature.

Если значение равно true, команды git-log[1], git-show[1] и git-whatchanged[1] предполагают, что --use-mailmap; в противном случае предполагают, что --no-use-mailmap. По умолчанию — true.

Может принимать значения «advertise» (по умолчанию), «allow» или «ignore». При значении «advertise» сервер ответит клиенту, отправившему «unborn» (как описано в gitprotocol-v2[5]), и объявит о поддержке этой функции при объявлении возможностей протокола версии 2. Значение «allow» аналогично «advertise», за исключением того, что сервер не объявляет о поддержке этой функции. Это полезно, например, для серверов с балансировкой нагрузки, которые нельзя обновить атомарно: администратор может настроить значение «allow», а затем, после задержки, — «advertise».

Если значение равно true, git-mailinfo[1] (и, следовательно, git-am[1]) по умолчанию работает так, как если бы в командной строке был указан параметр --scissors. При включении эта функция удаляет всё содержимое тела сообщения до строки-разделителя (то есть строки, состоящей в основном из «>8», «8<» и «-»).

Расположение дополнительного файла mailmap. Сначала загружается файл mailmap по умолчанию, расположенный в корне репозитория, затем — файл mailmap, указанный этой переменной. Файл mailmap может находиться в подкаталоге репозитория или за его пределами. См. git-shortlog[1] и git-blame[1].

Аналогично mailmap.file, но значение рассматривается как ссылка на blob в репозитории. Если заданы и mailmap.file, и mailmap.blob, обрабатываются оба файла, причём записи из mailmap.file имеют приоритет. В репозитории без рабочей копии по умолчанию используется HEAD:.mailmap. В обычном репозитории значение по умолчанию пустое.

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

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

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

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

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

Возможные стратегии:

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

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

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

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

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

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

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

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

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

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

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

Укажите программы, которые можно использовать для отображения справки в формате man. См. git-help[1].

Укажите команду для вызова заданной программы просмотра man-страниц. Указанная команда выполняется в оболочке, а страница man передаётся ей в качестве аргумента. (См. git-help[1].)

Переопределите путь к указанному инструменту, который можно использовать для отображения справки в формате man. См. git-help[1].

Задаёт стиль записи конфликтующих фрагментов в файлы рабочего дерева при слиянии. По умолчанию используется «merge»: выводится маркер конфликта <<<<<<<, изменения одной стороны, маркер =======, изменения другой стороны, а затем маркер >>>>>>>. Альтернативный стиль «diff3» добавляет маркер ||||||| и исходный текст перед маркером =======. Стиль «merge» обычно формирует меньшие конфликтующие области, чем diff3, как потому, что исходный текст исключён, так и потому, что совпадающие на обеих сторонах строки выделяются из области конфликта. Другой альтернативный стиль, «zdiff3», похож на diff3, но удаляет совпадающие строки обеих сторон из области конфликта, если они расположены близко к её началу или концу.

Если merge вызвана без аргумента-коммита, объединяет ветки, от которых зависит текущая ветка, используя их последние известные значения, сохранённые в ветках отслеживания удалённых репозиториев. Рассматриваются значения branch.<current branch>.merge, указывающие на ветки удалённого репозитория с именем, заданным параметром branch.<current-branch>.remote; затем они сопоставляются с соответствующими ветками отслеживания удалённых репозиториев через remote.<remote>.fetch, после чего объединяются вершины этих отслеживаемых веток. По умолчанию — true.

По умолчанию Git не создаёт дополнительный коммит слияния, если объединяемый коммит является потомком текущего. Вместо этого вершина текущей ветки перемещается вперёд без слияния. Если задано значение false, эта переменная указывает Git создать дополнительный коммит слияния в таком случае (это эквивалентно указанию параметра --no-ff в командной строке). Если задано значение only, разрешены только такие слияния с перемоткой вперёд (это эквивалентно указанию параметра --ff-only в командной строке).

Если значение равно true, это эквивалентно параметру командной строки --verify-signatures. Подробности см. в git-merge[1].

Помимо имён веток, добавляет в сообщение журнала связанное с ними описание ветки. По умолчанию — false.

Помимо имён веток, добавляет в сообщение журнала не более указанного числа однострочных описаний фактических объединяемых коммитов. По умолчанию — false; значение true является синонимом числа 20.

Если добавить в эту многозначную переменную конфигурации glob-шаблон, соответствующий именам интеграционных веток, стандартное сообщение слияния для слияний в эти интеграционные ветки не будет включать в заголовок фразу «into <branch-name>».

Элемент с пустым значением можно использовать для очистки списка glob-шаблонов, накопленного из предыдущих записей конфигурации. Если переменная merge.suppressDest не определена, для обратной совместимости используется значение master по умолчанию.

Число файлов, учитываемых при исчерпывающей части обнаружения переименований во время слияния. Если значение не задано, по умолчанию используется значение diff.renameLimit. Если не заданы ни merge.renameLimit, ни diff.renameLimit, в настоящее время по умолчанию используется 7000. Этот параметр не влияет на работу, если обнаружение переименований отключено.

Определяет, обнаруживает ли Git переименования. Если задано значение false, обнаружение переименований отключено. Если задано значение true, включено базовое обнаружение переименований. По умолчанию используется значение diff.renames.

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

Если merge.renames имеет значение false, параметр merge.directoryRenames игнорируется и рассматривается как false. По умолчанию используется значение conflict.

Сообщает Git, что каноническое представление файлов в репозитории менялось со временем (например, в ранних коммитах текстовые файлы записывались с окончаниями строк CRLF, а в более поздних используются окончания строк LF). В таком репозитории для каждого файла, требующего трёхстороннего слияния содержимого, Git может преобразовать данные, записанные в коммитах, в канонический формат перед слиянием, чтобы уменьшить число ненужных конфликтов. Дополнительные сведения см. в разделе «Слияние ветвей с различающимися атрибутами checkin/checkout» в gitattributes[5].

Определяет, что выводить, если вообще что-либо выводить, между ORIG_HEAD и результатом слияния в конце операции. Возможные значения:

Однако любое неизвестное значение (например, значение, добавленное в будущей версии Git) считается значением true, а не вызывает ошибку. По умолчанию используется значение true.

Если задано значение true, перед началом операции автоматически создаётся временная запись stash, а после её завершения она применяется. Это позволяет выполнять слияние в рабочем дереве с незакоммиченными изменениями. Однако используйте этот параметр с осторожностью: применение stash после успешного слияния может привести к нетривиальным конфликтам. Этот параметр можно переопределить параметрами --no-autostash и --autostash команды git-merge[1]. По умолчанию используется значение false.

Управляет выбором инструмента слияния для команды git-mergetool[1]. В списке ниже приведены допустимые встроенные значения. Любое другое значение рассматривается как пользовательский инструмент слияния; для него необходимо определить соответствующую переменную mergetool.<tool>.cmd.

Управляет выбором инструмента слияния для команды git-mergetool[1], если указан флаг -g/--gui. В списке ниже приведены допустимые встроенные значения. Любое другое значение рассматривается как пользовательский инструмент слияния; для него необходимо определить соответствующую переменную mergetool.<guitool>.cmd.

Управляет объёмом вывода, создаваемого рекурсивной стратегией слияния. Уровень 0 ничего не выводит, кроме итогового сообщения об ошибке, если обнаружены конфликты. Уровень 1 выводит только конфликты, уровень 2 — конфликты и изменения файлов. Уровень 5 и выше выводит отладочную информацию. По умолчанию используется уровень 2. Значение можно переопределить с помощью переменной окружения GIT_MERGE_VERBOSITY.

Задаёт понятное человеку имя для пользовательского низкоуровневого драйвера слияния. Подробности см. в gitattributes[5].

Задаёт команду, реализующую пользовательский низкоуровневый драйвер слияния. Подробности см. в gitattributes[5].

Задаёт имя низкоуровневого драйвера слияния, используемого при внутреннем слиянии общих предков. Подробности см. в gitattributes[5].

Переопределяет путь к указанному инструменту. Это полезно, если инструмент отсутствует в $PATH.

Задаёт команду для вызова указанного инструмента слияния. Команда выполняется в оболочке, где доступны следующие переменные: BASE — имя временного файла с общей базовой версией файлов для слияния, если она доступна; LOCAL — имя временного файла с содержимым файла из текущей ветви; REMOTE — имя временного файла с содержимым файла из сливаемой ветви; MERGED содержит имя файла, в который инструмент слияния должен записать результаты успешного слияния.

Позволяет пользователю переопределить глобальное значение mergetool.hideResolved для конкретного инструмента. Полное описание см. в mergetool.hideResolved.

Для пользовательской команды слияния задаёт, можно ли использовать код завершения команды, чтобы определить, успешно ли выполнено слияние. Если для этого параметра не задано значение true, проверяется временная метка целевого файла слияния; слияние считается успешным, если файл был обновлён. В противном случае пользователю предлагается указать, успешно ли выполнено слияние.

Старые версии meld не поддерживают параметр --output. Git попытается определить, поддерживает ли meld параметр --output, проверив вывод команды meld --help. Настройка mergetool.meld.hasOutput заставит Git пропустить эти проверки и использовать заданное значение. Установка для mergetool.meld.hasOutput значения true сообщает Git, что параметр --output нужно использовать безусловно; значение false предотвращает использование --output.

Если указан параметр --auto-merge, meld автоматически объединит все части без конфликтов, выделит конфликтующие части и дождётся решения пользователя. Установка для mergetool.meld.useAutoMerge значения true сообщает Git, что параметр --auto-merge с meld нужно использовать безусловно. Если установить для этого параметра значение auto, Git определит, поддерживается ли --auto-merge, и будет использовать --auto-merge только при наличии такой поддержки. Значение false полностью предотвращает использование --auto-merge и устанавливается по умолчанию.

Настраивает расположение разделённых окон для <variant> vimdiff; допустимы значения vimdiff, nvimdiff, gvimdiff. При запуске git mergetool с параметром --tool=<variant> (или без --tool, если для merge.tool задано значение <variant>) Git проверит mergetool.<variant>.layout, чтобы определить расположение окон инструмента. Если конфигурация для конкретного варианта недоступна, используется значение vimdiff ' s. Если и оно недоступно, будет использовано расположение по умолчанию с четырьмя окнами. О настройке расположения см. раздел BACKEND SPECIFIC HINTS в git-mergetool[1].

Во время слияния Git автоматически разрешает как можно больше конфликтов и записывает файл $MERGED, содержащий маркеры конфликтов вокруг конфликтов, которые не удалось разрешить; $LOCAL и $REMOTE обычно содержат версии файла до разрешения конфликтов Git. Этот флаг приводит к перезаписи $LOCAL и $REMOTE, чтобы инструменту слияния передавались только неразрешённые конфликты. Можно настроить отдельно для каждого инструмента с помощью переменной конфигурации mergetool.<tool>.hideResolved. По умолчанию используется значение false.

После слияния исходный файл с маркерами конфликтов можно сохранить в файле с расширением .orig. Если для этой переменной задано значение false, этот файл не сохраняется. По умолчанию используется значение true (то есть резервные копии сохраняются).

При вызове пользовательского инструмента слияния Git передаёт ему набор временных файлов. Если инструмент возвращает ошибку и для этой переменной задано значение true, временные файлы сохраняются; в противном случае они удаляются после завершения работы инструмента. По умолчанию используется значение false.

По умолчанию Git записывает временные версии BASE, LOCAL и REMOTE конфликтующих файлов в рабочем дереве. Если задано значение true, Git попытается использовать для этих файлов временный каталог. По умолчанию используется значение false.

Запрашивать подтверждение перед каждым запуском программы разрешения конфликтов.

Задайте значение true, чтобы по умолчанию использовать merge.guitool (эквивалентно указанию аргумента --gui), или значение auto, чтобы выбирать merge.guitool или merge.tool в зависимости от наличия значения переменной окружения DISPLAY. По умолчанию используется значение false; в этом случае аргумент --gui необходимо явно указать, чтобы использовать merge.guitool.

Стратегия слияния, выбираемая по умолчанию при разрешении конфликтов в заметках. Должна иметь одно из значений: manual, ours, theirs, union или cat_sort_uniq. По умолчанию используется значение manual. Дополнительные сведения о каждой стратегии см. в разделе «NOTES MERGE STRATEGIES» в git-notes[1].

Эту настройку можно переопределить, передав параметр --strategy команде git-notes[1].

Стратегия слияния, выбираемая при слиянии заметок в refs/notes/<name>. Переопределяет более общий параметр notes.mergeStrategy. Дополнительные сведения о доступных стратегиях см. в разделе «NOTES MERGE STRATEGIES» в git-notes[1].

Ссылка (или ссылки, если указана маска либо параметр задан несколько раз), из которой следует читать заметки при показе сообщений коммитов с помощью команд семейства git log, в дополнение к набору по умолчанию, заданному параметром core.notesRef или GIT_NOTES_REF.

Эту настройку можно переопределить переменной окружения GIT_NOTES_DISPLAY_REF, значением которой должен быть список ссылок или масок, разделённых двоеточиями.

Если указанные ссылки не существуют, будет выведено предупреждение; маски, которым не соответствует ни одна ссылка, молча игнорируются.

Эту настройку можно отключить параметром --no-notes для команд семейства git-log[1] либо параметром --notes=<ref>, принимаемым этими командами.

Эффективное значение core.notesRef (возможно, переопределённое значением GIT_NOTES_REF) также неявно добавляется в список отображаемых ссылок.

При переписывании коммитов с помощью <command> (в настоящее время amend или rebase), если значение этой переменной — false, git не будет копировать заметки из исходного коммита в переписанный. По умолчанию используется значение true. См. также параметр notes.rewriteRef ниже.

Эту настройку можно переопределить переменной окружения GIT_NOTES_REWRITE_REF, значением которой должен быть список ссылок или масок, разделённых двоеточиями.

Определяет, что делать при копировании заметок во время переписывания (см. параметр notes.rewrite.<command>), если целевой коммит уже содержит заметку. Должно быть задано одно из значений: overwrite, concatenate, cat_sort_uniq или ignore. По умолчанию используется значение concatenate.

Эту настройку можно переопределить переменной окружения GIT_NOTES_REWRITE_MODE.

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

Значение по умолчанию отсутствует; чтобы включить переписывание заметок, необходимо настроить эту переменную. Задайте ей значение refs/notes/commits, чтобы включить переписывание заметок для коммитов по умолчанию.

Настройку можно переопределить переменной окружения GIT_NOTES_REWRITE_REF. Дополнительное описание её формата см. выше в разделе notes.rewrite.<command>.

Размер окна, используемого командой git-pack-objects[1], если размер окна не указан в командной строке. По умолчанию — 10.

Максимальная глубина дельт, используемая командой git-pack-objects[1], если максимальная глубина не указана в командной строке. По умолчанию — 50. Максимальное значение — 4095.

Максимальный объём памяти, который каждый поток команды git-pack-objects[1] может использовать для окна памяти пакета, если лимит не задан в командной строке. К значению можно добавить суффикс «k», «m» или «g». Если параметр не настроен (или явно установлен в 0), ограничение отсутствует.

Целое число от -1 до 9, задающее уровень сжатия объектов в файле пакета. Значение -1 соответствует значению по умолчанию zlib. Значение 0 означает отсутствие сжатия, а значения от 1 до 9 задают различные компромиссы между скоростью и размером; значение 9 обеспечивает самое медленное сжатие. Если параметр не задан, используется значение core.compression. Если и оно не задано, используется -1 — значение zlib по умолчанию, которое представляет собой «компромисс между скоростью и сжатием (в настоящее время соответствует уровню 6)».

Обратите внимание: изменение уровня сжатия не приводит к автоматическому пересжатию всех существующих объектов. Принудительно пересжать их можно, передав параметр -F команде git-repack[1].

Если задано значение true или «single» и включены битовые карты достижимости, pack-objects попытается отправлять части файла пакета с битовой картой без изменений. Если задано значение «multi» и доступна битовая карта достижимости для нескольких пакетов, pack-objects попытается отправлять части всех пакетов в MIDX.

Если доступна только битовая карта для одного пакета, а для pack.allowPackReuse задано значение «multi», повторно используются части только файла пакета с битовой картой. Это может снизить расход памяти и процессорного времени при обслуживании fetch-запросов, но может привести к отправке немного большего пакета. По умолчанию используется значение true.

Расширенное регулярное выражение, задающее набор островов дельт. Подробности см. в разделе «DELTA ISLANDS» в git-pack-objects[1].

Задаёт имя острова, объекты которого должны быть упакованы первыми. Это создаёт в начале одного из пакетов своего рода псевдопакет, чтобы объекты указанного острова можно было быстрее скопировать в любой пакет, который будет передан пользователю, запросившему эти объекты. На практике это означает, что указанный остров, скорее всего, должен соответствовать наиболее часто клонируемой части репозитория. См. также раздел «DELTA ISLANDS» в git-pack-objects[1].

Максимальный объём памяти в байтах, используемый для кэширования дельт командой git-pack-objects[1] перед их записью в пакет. Этот кэш ускоряет этап записи объектов, позволяя не вычислять повторно окончательный результат дельты после нахождения наилучшего соответствия для всех объектов. Однако перепаковка крупных репозиториев на машинах с нехваткой памяти может заметно замедлиться, особенно если из-за этого кэша система начнёт использовать подкачку. Значение 0 означает отсутствие ограничения. Минимальный размер — 1 байт; его можно использовать, чтобы фактически отключить кэш. По умолчанию — 256 МиБ.

Максимальный размер дельты, кэшируемой командой git-pack-objects[1]. Этот кэш ускоряет этап записи объектов, позволяя не вычислять повторно окончательный результат дельты после нахождения наилучшего соответствия для всех объектов. По умолчанию — 1000. Максимальное значение — 65535.

Задаёт число потоков, запускаемых для поиска наилучших соответствий дельт. Для этого требуется, чтобы git-pack-objects[1] была собрана с поддержкой pthreads; в противном случае этот параметр игнорируется с предупреждением. Это позволяет сократить время упаковки на многопроцессорных машинах. Однако требуемый объём памяти для окна поиска дельт умножается на число потоков. Значение 0 заставляет Git автоматически определять число процессоров и соответствующим образом задавать число потоков.

Задаёт версию индекса пакета по умолчанию. Допустимые значения: 1 — устаревший формат индекса пакета, использовавшийся в версиях Git до 1.5.2; 2 — новый формат индекса пакета, поддерживающий пакеты размером более 4 ГБ и обеспечивающий надлежащую защиту от перепаковки повреждённых пакетов. По умолчанию используется версия 2. Обратите внимание: если соответствующий пакет превышает 2 ГБ, принудительно используется версия 2, а этот параметр конфигурации игнорируется.

Если у вас старая версия Git, не распознающая файл *.idx версии 2, клонирование или получение данных по протоколу, отличному от собственного (например, «http»), при котором копируются и файл *.pack, и соответствующий файл *.idx с другой стороны, может привести к созданию репозитория, недоступного для вашей старой версии Git. Однако если размер файла *.pack меньше 2 ГБ, можно использовать git-index-pack[1] для файла *.pack, чтобы заново создать файл *.idx.

Максимальный размер пакета. Эта настройка влияет только на упаковку в файл при повторной упаковке, то есть на протокол git:// она не влияет. Её можно переопределить параметром --max-pack-size команды git-repack[1]. При достижении этого ограничения создаётся несколько файлов пакетов.

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

Если вам необходимо активно использовать Git с файлами пакетов меньшего размера (например, потому что ваша файловая система не поддерживает большие файлы), эта настройка может помочь. Но если вы хотите передать файл пакета через носитель с ограничением по размеру (например, съёмный носитель, на котором не помещается весь репозиторий), скорее всего, лучше создать один большой файл пакета и разделить его с помощью универсальной программы для создания многотомных архивов (например, Unix split).

Минимально допустимый размер ограничен 1 МиБ. По умолчанию ограничение отсутствует. Поддерживаются распространённые суффиксы единиц измерения k, m или g.

Если значение равно true, Git будет использовать битовые карты пакетов (если они доступны) при упаковке в stdout (например, на стороне сервера во время fetch). По умолчанию — true. Обычно отключать эту настройку не нужно, за исключением случаев отладки битовых карт пакетов.

Если значение равно true, Git будет использовать экспериментальный алгоритм для вычисления запросов достижимости с помощью битовых карт. Вместо построения полных битовых карт для всех исключённых вершин и последующего объединения их операцией OR, исключённые вершины с существующими битовыми картами рассматриваются как добавочные (то есть включаются в результат с помощью OR, если они существуют, и игнорируются в противном случае), а битовая карта строится на границе.

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

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

Если значение равно true, Git по умолчанию будет использовать параметр --sparse в git pack-objects, если присутствует параметр --revs. Этот алгоритм обходит только деревья, встречающиеся в путях, в которых добавляются новые объекты. Это может значительно повысить производительность при вычислении пакета для отправки небольшого изменения. Однако в файл пакета могут попасть лишние объекты, если включённые коммиты содержат определённые типы прямых переименований. По умолчанию — true.

Включает по умолчанию параметр --path-walk для процессов git pack-objects. Полное описание см. в git-pack-objects[1].

Задаёт иерархию ссылок (например, "refs/heads/"); для указания нескольких иерархий этот параметр можно задать несколько раз. При выборе коммитов, для которых будут созданы битовые карты, предпочтение отдаётся коммиту на вершине ссылки, входящей в любую из настроенных иерархий.

Обратите внимание, что присвоение этому параметру значения refs/foo/ не означает, что коммиты на вершинах refs/foo/bar и refs/foo/baz обязательно будут выбраны. Это связано с тем, что коммиты для битовых карт выбираются из последовательности окон переменной длины.

Если в окне встречается коммит на вершине любой ссылки, являющейся суффиксом любого значения этого параметра, он немедленно получает преимущество перед любым другим коммитом в этом окне.

Это устаревший синоним параметра repack.writeBitmaps.

Если значение равно true, Git будет включать раздел «hash cache» в индекс битовых карт (если он записывается). Этот кэш можно использовать для эвристик Git при вычислении дельт, что потенциально позволяет получать более качественные дельты между объектами с битовыми картами и без них (например, при обслуживании fetch между старым пакетом с битовыми картами и объектами, отправленными после последнего gc). Недостаток в том, что для него требуется 4 байта дискового пространства на объект. По умолчанию — true.

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

Если значение равно true, Git будет включать раздел «lookup table» в индекс битовых карт (если он записывается). Эта таблица позволяет отложить загрузку отдельных битовых карт как можно дольше. Это может быть полезно в репозиториях с относительно большими индексами битовых карт. По умолчанию — false.

Если значение равно true, Git будет читать все доступные файлы .rev (см. gitformat-pack[5]). Если значение равно false, обратный индекс будет создан с нуля и сохранён в памяти. По умолчанию — true.

Если значение равно true, Git будет записывать соответствующий файл .rev (см. gitformat-pack[5]) для каждого нового файла пакета во всех случаях, кроме git-fast-import[1] и механизма массовой фиксации изменений. По умолчанию — true.

Если значение логическое, включает или отключает постраничный вывод результатов конкретной подкоманды Git при записи в tty. В противном случае включает постраничный вывод для подкоманды с помощью программы постраничного вывода, заданной значением pager.<cmd>. Если в командной строке указан параметр --paginate или --no-pager, он имеет приоритет над этой настройкой. Чтобы отключить постраничный вывод для всех команд, задайте для core.pager или GIT_PAGER значение cat.

Псевдоним строки формата --pretty=, описанной в git-log[1]. Любые заданные здесь псевдонимы можно использовать так же, как встроенные форматы pretty. Например, выполнение git config pretty.changelog "format:* %H %s" приведёт к тому, что вызов git log --pretty=changelog будет эквивалентен выполнению git log "--pretty=format:* %H %s". Обратите внимание, что псевдоним с тем же именем, что и у встроенного формата, будет молча проигнорирован.

Если задано значение "true", при получении дополнительных объектов для частичного клона предполагается --quiet.

Если задано значение "true", сервер будет использовать возможность "promisor-remote" (см. gitprotocol-v2[5]), чтобы сообщать об используемых им promisor-удалённых репозиториях, если таковые имеются. По умолчанию задано значение "false", то есть возможность "promisor-remote" не объявляется.

Список дополнительных имён полей, связанных с удалёнными репозиториями, разделённых запятыми или пробелами. При объявлении promisor-удалённых репозиториев с помощью возможности "promisor-remote" сервер отправляет эти имена полей и связанные с ними значения из своей конфигурации (см. gitprotocol-v2[5]). В настоящее время поддерживаются только имена полей "partialCloneFilter" и "token".

содержит фильтр частичного клонирования, используемый для удалённого репозитория.

содержит токен аутентификации для удалённого репозитория.

Если имя поля входит в этот список, а на сервере задана соответствующая переменная конфигурации "remote.foo.<field-name>" с непустым значением, то имя поля и его значение отправляются при объявлении promisor-удалённого репозитория "foo".

Этот список не действует, если для переменной конфигурации "promisor.advertise" не задано значение "true"; поля "name" и "url" всегда объявляются независимо от этой настройки.

Если задано значение "all", клиент принимает все promisor-удалённые репозитории, которые сервер может объявить с помощью возможности "promisor-remote". Если задано значение "knownName", клиент принимает promisor-удалённые репозитории, уже настроенные на клиенте и имеющие те же имена, что и объявленные клиентом. Это не очень безопасно, но может использоваться в корпоративной среде, где серверы и клиенты считаются надёжными и не будут менять имена и URL. Если задано значение "knownUrl", клиент принимает promisor-удалённые репозитории, для которых и имя, и URL, настроенные на клиенте, совпадают с объявленными сервером. Это безопаснее, чем "all" или "knownName", поэтому по возможности следует использовать именно этот вариант. По умолчанию задано значение "none", то есть ни один promisor-удалённый репозиторий, объявленный сервером, не будет принят. Принимая promisor-удалённый репозиторий, клиент соглашается с тем, что сервер может не включать в ответы на запросы клиента "fetch" и "clone" объекты, которые можно отложенно получить из этого promisor-удалённого репозитория. Сравнение имён и URL чувствительно к регистру. См. gitprotocol-v2[5].

Список дополнительных имён полей, связанных с удалёнными репозиториями, разделённых запятыми или пробелами. Прежде чем принять promisor-удалённый репозиторий, клиент проверяет, совпадают ли значения этих полей, переданные сервером, со значениями полей в собственной конфигурации. В настоящее время поддерживаются только поля "partialCloneFilter" и "token".

Если одно из этих имён полей (например, "token") проверяется для объявленного promisor-удалённого репозитория (например, "foo"), для успешного прохождения проверки этого поля должны выполняться три условия: