Расширение оболочки в git config

У меня есть переменная оболочки, которая указывает на каталог, где находятся все мои файлы конфигурации. Давайте предположим, что переменная создана с export RC=$HOME/rc, У меня есть глобальный файл игнорирования в каталоге конфигурации: ~/rc/globalgitignore,

Мой вопрос, как я могу расширить RC переменная в моем .gitconfig файл?

Я уже попробовал следующее:

  • excludesfile = $RC/globalgitignore

  • excludesfile = !$RC/globalgitignore

  • excludesfile = !echo $RC/globalgitignore

  • excludesfile = !$(echo $RC/globalgitignore)

Ни одно из этих решений не работает.

Единственный способ это работает, если я введу полный путь: excludesfile = ~/rc/globalgitignore, но тогда я должен изменить путь, если переместить мой rc каталог в другое место.

3 ответа

Решение

Ты не можешь git-config(1) не поддерживает расширение переменных среды, а только ограниченное преобразование типов и расширение пути:

Спецификатор типа может быть либо --int, либо --bool, чтобы git config гарантировал, что переменная (и) имеет заданный тип, и преобразовал значение в каноническую форму (простое десятичное число для int, "true" или "ложная" строка для bool), или --path, которая выполняет расширение пути (см. --path ниже). Если спецификатор типа не передан, никакие проверки или преобразования не выполняются для значения.

Документация для --path состояния:

--дорожка

git-config развернет, ведя ~ к значению $HOME, и ~user к домашнему каталогу для указанного пользователя. Эта опция не действует при установке значения (но вы можете использовать git config bla ~/ из командной строки, чтобы позволить вашей оболочке выполнить расширение).

Термин "расширение" не появляется в каком-либо ином контексте в git-config(1), Так как же вы поняли, что так и должно быть, учитывая, что ни одна такая функция нигде не описана?

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

Если речь идет об управлении точечным файлом, то делайте то, что делают все люди: поместите их в каталог и добавьте символические ссылки в этот каталог из своего $HOME,

Я использую скрипты bash в моей конфигурации, чтобы включить расширение переменных. Просто экспортируйте нужную переменную в ваш.bashrc и используйте ее в скриптах:

В моем ~/.bashrc:

export TESTVARIABLE="hello"

В моем ~/.gitconfig:

[alias]
    test = !bash -c '"echo \"Value: $TESTVARIABLE\";"'

В моем приглашении bash:

bash> git test
    Value: hello 

Другой способ сделать это - добавить команду git config в rc вашей оболочки. Я, например, в моем.bashrc:

git config --global user.name "$USER@$HOSTNAME"

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

export RC="$HOME/rc"
git config --global core.excludesfile "$RC/globalgitignore" 

В Git 2.31 (первый квартал 2021 г.) вы можете рассмотреть возможность использования пар «переменная-значение» конфигурации через переменные среды (и он настраивает способ кодирования пар «переменная / значение», чтобы сделать его более надежным).

Смотрите , фиксацию b9d147f , фиксацию 1ff21c0, фиксацию b342ae6, (12 января 2021 г.) и фиксацию b0812b6 (7 января 2021 г.) от .
См. Commit f9dbb64, commit 13c4495 (12 января 2021 г.) Джефф Кинг ( peff).
(Объединено в коммите 294e949, 25 января 2021 г.)

фиксацию ce81b1d: добавить новый способ передачи конфигурации через

Соавтор: Джефф Кинг
Подписанный: Патрик Стейнхардт

Хотя уже можно передать конфигурацию времени выполнения через git -c <key>=<value>( ), может быть нежелательно использовать, если значение содержит конфиденциальную информацию.
Например,
если кто-то хочет установить, чтобы он содержал токен аутентификации, выполнение этого через тривиально приведет к утечке этих учетных данных через, например, что обычно также показывает аргументы команды.

Чтобы включить этот вариант использования без утечки учетных данных, этот коммит вводит новый переключатель --config-env=<key>=<envvar>.

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

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

[--super-prefix=<path>] [--config-env <name>=<envvar>]

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

--config-env=<name>=<envvar>

Нравиться -c <name>=<value>, присвойте переменной конфигурации '' значение, где - имя переменной среды, из которой нужно получить значение.

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

Это ошибка, если в среде не существует. <envvar> не может содержать знак равенства, чтобы избежать двусмысленности с <name>s, которые содержат один.

Это полезно в случаях, когда вы хотите передать временные параметры конфигурации в git, но делаете это в ОС, где другие процессы могут читать вашу командную строку (например, /proc/self/cmdline), но не ваше окружение (например, /proc/self/environ).
Это поведение по умолчанию в Linux, но может отсутствовать в вашей системе.

Обратите внимание, что это может добавить безопасности для переменных, например, когда конфиденциальная информация является частью значения, но не, например, url.<base>.insteadOf где конфиденциальная информация может быть частью ключа.

В вашем случае проверьте это с помощью:

      git --config-env=core.excludesfile=RC config core.excludesfile
# or (Git 2.32+ only)
git --config-env core.excludesfile=RC config core.excludesfile

Значение для core.excludesfile должно быть $RC (который должен ссылаться на полный путь к файлу, а не только на его родительскую папку)


Примечание. До Git 2.32 (второй квартал 2021 г.) "git --config-env var=val cmd" (мужчина )не были приняты (только --config-env=var=val было).

См. , фиксацию 9152904 (29 апреля 2021 г.) Патрика Стейнхардта ()Патрика Стейнхардта ( pks-t) .
(Слияние Junio ​​C Hamano --Junio ​​C Hamano - gitster- в коммите 5f586f5, 07 мая 2021 г.)

Фиксацию c331551git: поддержка отдельного аргумента для значения

Подписано: Патрик Стейнхардт
Рецензент: Джефф Кинг

Хотя это и не задокументировано, многие параметры верхнего уровня, такие как --git-dir а также --work-treeподдерживают два синтаксиса: они принимают знак равенства между параметром и его значением, и они поддерживают параметр и значение как два отдельных аргумента.
Недавно добавленные --config-env опция поддерживает только синтаксис со знаком равенства.

Устраните это несоответствие, приняв оба синтаксиса и добавив тесты для проверки их работы.


Но это еще не все, с Git 2.31:

фиксацию d8d7715config: разрешить указание записей конфигурации через пары envvar

Подписано: Патрик Стейнхардт

Пока у нас есть GIT_CONFIG_PARAMETERS переменная среды, которая может использоваться для передачи данных конфигурации времени выполнения в процессы git, это внутренняя деталь реализации, которая не должна использоваться конечными пользователями.

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

Таким образом, этот коммит добавляет новый способ добавления записей конфигурации через среду, который устраняет этот недостаток.
Если пользователь проходит GIT_CONFIG_COUNT=$n переменная среды, Git проанализирует пары переменных среды GIT_CONFIG_KEY_$i а также GIT_CONFIG_VALUE_$i для каждого i в [0,n).

Хотя того же можно достичь с помощью git -c <name>=<value>(manмужчина ), можно не делать этого для потенциально конфиденциальной информации.
Например,
если нужно установить http.extraHeader чтобы содержать токен аутентификации, делая это через -c приведет к тривиальной утечке этих учетных данных через, например, ps(1), который обычно также показывает аргументы команды.

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

Если установлено положительное число, все пары среды GIT_CONFIG_KEY_<n> а также GIT_CONFIG_VALUE_<n> до этого числа будет добавлено в конфигурацию времени выполнения процесса.

Пары конфигураций имеют нулевой индекс.
Любой отсутствующий ключ или значение рассматривается как ошибка. Пустой GIT_CONFIG_COUNT рассматривается так же, как GIT_CONFIG_COUNT=0, а именно пары не обрабатываются.
Эти переменные среды будут переопределять значения в файлах конфигурации, но будут переопределены любыми явными параметрами, переданными через git -c.

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

Например:

          GIT_CONFIG_COUNT=2 \
        GIT_CONFIG_KEY_0="pair.one" GIT_CONFIG_VALUE_0="foo" \
        GIT_CONFIG_KEY_1="pair.two" GIT_CONFIG_VALUE_1="bar" \
        git config --get-regexp "pair.*" 

напечатает:

      pair.one foo
pair.two bar
Другие вопросы по тегам