在git config中进行Shell变量扩展

Sve*_*enK 51 git shell

我有一个shell变量,指向我所有配置文件所在的目录.我们假设变量是用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目录移动到其他位置,我必须更改路径.

lun*_*orn 40

你不能.git-config(1)不支持环境变量扩展,只支持有限的类型转换和路径扩展:

类型说明符可以是--int或--bool,以使git config确保变量具有给定类型并将值转换为规范形式(int的简单十进制数,"true"或bool的"false"字符串)或--path,它执行一些路径扩展(参见下面的--path).如果传递任何类型说明符,则不对该值执行任何检查或转换.

--path各州的文件:

- 路径

git-config将扩展前导〜$ HOME的值,并将~user扩展到指定用户的主目录.设置值时此选项无效(但您可以使用命令行中的git config bla~ /来让shell执行扩展).

"扩展"一词并未出现在任何不同的背景下git-config(1).那么你怎么能得到它应该的想法,因为在任何地方都没有记录这样的特征?

为了扩展环境变量,您必须自己预处理Git配置文件,即创建模板文件,并在将文件复制到$HOME目录之前使用脚本扩展变量.

如果它是关于dotfile管理,那么做,所有人都做:将它们放在一个目录中,并从你的目录中添加符号链接到这个目录$HOME.

  • @SvenK:请阅读`git-config(1)`:`git-config(1)`扩展`~`不会"自动"意味着支持变量扩展甚至shell命令.`~`由`git-config`专门处理*当且仅当使用`--path`类型说明符*检索值时.这是`git-config`支持的*唯一*扩展.我已经更新了我的答案,包括`git-config(1)`中的相关部分 (3认同)
  • 这有点令人沮丧,因为我不能只为我的整个系统指定我的http [s]?_ proxy环境变量; 我必须出于某种原因在我的gitconfig中指定它.对于不在家或小型开发商店工作的人和/或根据他们工作地点而坐在不同网络上的人来说,这很烦人. (2认同)

gos*_*pes 23

我在配置中使用bash脚本来启用变量扩展.只需在.bashrc中导出所需的变量并在脚本中使用它:

在我的〜/ .bashrc中:

export TESTVARIABLE="hello"
Run Code Online (Sandbox Code Playgroud)

在我的〜/ .gitconfig中:

[alias]
    test = !bash -c '"echo \"Value: $TESTVARIABLE\";"'
Run Code Online (Sandbox Code Playgroud)

在我的bash提示符下:

bash> git test
    Value: hello 
Run Code Online (Sandbox Code Playgroud)

另一种方法是在shell的rc中添加一个git config命令.我举例说明我的.bashrc:

git config --global user.name "$USER@$HOSTNAME"
Run Code Online (Sandbox Code Playgroud)

我在所有机器上都有相同的配置,通过添加它我可以区分来自不同机器的提交.您可以这样做并添加到您的shell rc:

export RC="$HOME/rc"
git config --global core.excludesfile "$RC/globalgitignore" 
Run Code Online (Sandbox Code Playgroud)

  • @tivoni @gospes的例子才有效,因为它在`git alias`组中 (9认同)

Von*_*onC 18

使用 Git 2.31(2021 年第 1 季度),您可以考虑通过环境变量使用配置变量值对(并且它调整了GIT_CONFIG_PARAMETERS编码变量/值对的方式以使其更加健壮)。

请参阅提交 d8d7715提交 b9d147f提交 1ff21c0提交 b342ae6提交 ce81b1d(2021 年 1 月 12 日)和提交 b0812b6(2021 年 1 月 07 日),作者:Patrick Steinhardt ( pks-t)
请参阅Jeff King的提交 f9dbb64提交 13c4495(2021 年 1 月 12 日(由Junio C Hamano 合并 -- --提交 294e949中,2021 年 1 月 25 日)peff
gitster

config:添加新的方式来传递配置--config-env

合著者:杰夫·金
签字人:帕特里克·斯坦哈特

虽然已经可以通过( man )传递运行时配置,但当值包含敏感信息时可能不宜使用。 例如 ,如果想要设置为包含身份验证令牌,那么 via会通过 eg 轻易泄漏这些凭据,eg 通常也会显示命令参数。git -c <key>=<value>

http.extraHeader-cps(1)

为了在不泄露凭据的情况下启用此用例,此提交引入了一个新的 switch --config-env=<key>=<envvar>

它不是直接传递给定键的值,而是允许用户指定环境变量的名称。
该变量的值将用作键的值。

git现在包含在其手册页中:

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

git现在包含在其手册页中:

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

例如-c <name>=<value>,为配置变量“ <name>”提供一个值,其中<envvar>是要从中检索该值的环境变量的名称。

与没有直接将值设置为空字符串的快捷方式不同 -c,环境变量本身必须设置为空字符串。

<envvar>如果环境中不存在则出错。<envvar>不得包含等号以避免与<name>包含 1 的 s 产生歧义。

这对于以下情况很有用:您想要将临时配置选项传递给 git,但在其他进程可能能够读取您的命令行(例如/proc/self/cmdline)但不能读取您的环境(例如/proc/self/environ)的操作系统上这样做。
该行为是 Linux 上的默认行为,但在您的系统上可能不是。

请注意,这可能会增加变量的安全性,例如 http.extraHeader敏感信息是值的一部分,但不会增加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
Run Code Online (Sandbox Code Playgroud)

的值core.excludesfile应该是$RC(它应该引用完整的文件路径,而不仅仅是其父文件夹)


注意:在 Git 2.32(2021 年第二季度)之前,“ git --config-env var=val cmdman被接受(仅--config-env=var=val被接受)。

请参阅帕特里克·斯坦哈特 (Patrick Steinhardt )的提交 c331551提交 9152904(2021 年 4 月 29 日)。(由Junio C Hamano 合并 -- --提交 5f586f5中,2021 年 5 月 7 日)pks-t
gitster

git: 支持单独的参数来表示 的--config-env

签署人:Patrick Steinhardt
审阅人:Jeff King

虽然没有这样记录,但许多顶级选项喜欢--git-dir--work-tree支持两种语法:它们接受选项及其值之间的等号,并且它们支持选项和值作为两个单独的参数。
最近添加的--config-env选项仅支持带等号的语法。

通过接受这两种语法并添加测试来验证这两种语法可以缓解这种不一致。


但 Git 2.31 还提供更多功能:

config:允许通过环境变量对指定配置条目

签署人:帕特里克·斯坦哈特

虽然我们目前拥有GIT_CONFIG_PARAMETERS可用于将运行时配置数据传递给 git 进程的环境变量,但它是内部实现细节,不应该由最终用户使用。

除了仅供内部使用之外,这种传递配置条目的方式还有一个主要缺点:需要解析配置键,因为它们在单个变量中同时包含键和值。
因此,用户需要转义值中的任何潜在有害字符,如果值由第三方控制,则很难做到这一点。

因此,此提交添加了一种通过环境添加配置条目的新方法,从而消除了此缺点。
如果用户传递GIT_CONFIG_COUNT=$n环境变量,Git 将解析环境变量对GIT_CONFIG_KEY_$i,并GIT_CONFIG_VALUE_$ii每个[0,n).

虽然使用( man )可以实现同样的目的,但对于潜在的敏感信息,人们可能不希望这样做。 例如 ,如果想要设置为包含身份验证令牌,那么 via会通过 eg 轻易泄漏这些凭据,eg 通常也会显示命令参数。git -c <name>=<value>

http.extraHeader-cps(1)

git config现在包含在其手册页中:

GIT_CONFIG_COUNT

GIT_CONFIG_KEY_<n>

GIT_CONFIG_VALUE_<n>

如果GIT_CONFIG_COUNT设置为正数,则所有环境对 GIT_CONFIG_KEY_<n>以及GIT_CONFIG_VALUE_<n>最多该数字都将添加到进程的运行时配置中。

配置对是零索引的。
任何缺失的键或值都将被视为错误。空的GIT_CONFIG_COUNT处理方式与 相同GIT_CONFIG_COUNT=0,即不处理任何对。
这些环境变量将覆盖配置文件中的值,但将被通过git -c.

这对于您想要使用通用配置生成多个 git 命令但不能依赖于配置文件的情况非常有用,例如在编写脚本时。

例如:

git --config-env=core.excludesfile=RC config core.excludesfile
# or (Git 2.32+ only)
git --config-env core.excludesfile=RC config core.excludesfile
Run Code Online (Sandbox Code Playgroud)

将打印:

pair.one foo
pair.two bar
Run Code Online (Sandbox Code Playgroud)