使用 Git 2.31(2021 年第一季度),您可以考虑通过环境变量使用配置变量-值对(它调整了 GIT_CONFIG_PARAMETERS 编码变量/值对的方式,使其也更加健壮)。
请参阅commit d8d7715、commit b9d147f、commit 1ff21c0、commit b342ae6、commit ce81b1d(2021 年 1 月 12 日)和 commit b0812b6(2021 年 1 月 7 日)Patrick Steinhardt (pks-t)。
请参阅 Jeff King (peff) 的 commit f9dbb64、commit 13c4495(2021 年 1 月 12 日)。
(由 Junio C Hamano -- gitster -- 合并到 commit 294e949,2021 年 1 月 25 日)
config:添加通过--config-env 传递配置的新方法
合着:Jeff King
署名:Patrick Steinhardt
虽然已经可以通过 git -c <key>=<value>(man) 传递运行时配置,但当值包含敏感信息时可能不适合使用。
例如
如果想将http.extraHeader 设置为包含一个身份验证令牌,那么通过-c 这样做会轻易地泄露这些凭据,例如ps(1),通常还显示命令参数。
为了在不泄露凭据的情况下启用此用例,此提交引入了一个新开关 --config-env=<key>=<envvar>。
它不是直接为给定键传递值,而是允许用户指定环境变量的名称。
然后该变量的值将用作键的值。
git 现在包含在其man page 中:
[--super-prefix=<path>] [--config-env <name>=<envvar>]
git 现在包含在其man page 中:
--config-env=<name>=<envvar>
如-c <name>=<value>,给出配置变量
'<name>' 一个值,其中<envvar> 是一个名称
从中检索值的环境变量。
不像
-c 没有直接将值设置为
空字符串,而环境变量本身必须是
设置为空字符串。
如果<envvar> 不存在则错误
在环境中。 <envvar> 不能包含等号
避免与包含一个的 <name>s 产生歧义。
这对于您想要传递临时性的情况很有用
git 的配置选项,但在操作系统的 where 上这样做
其他进程可能能够读取您的命令行
(例如/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
core.excludesfile 的值应该是 $RC(它应该引用完整的文件路径,而不仅仅是它的父文件夹)
注意:在 Git 2.32(2021 年第二季度)之前,“git --config-env var=val cmd”(man)不被接受(只有 --config-env=var=val 被接受)。
参见commit c331551、commit 9152904(2021 年 4 月 29 日)Patrick Steinhardt (pks-t)。
(由 Junio C Hamano -- gitster -- 合并到 commit 5f586f5,2021 年 5 月 7 日)
git: 支持 --config-env 值的单独 arg
签字人:Patrick Steinhardt
审核人:Jeff King
虽然没有这样记录,但许多顶级选项,如 --git-dir 和 --work-tree 支持两种语法:它们接受选项及其值之间的等号,并且它们支持选项和值作为两个独立的论据。
最近添加的--config-env 选项仅支持带等号的语法。
通过接受这两种语法并添加测试来验证这两种语法来缓解这种不一致。
但还有更多,仍然使用 Git 2.31:
config: 允许通过 envvar 对指定配置条目
签字人:Patrick Steinhardt
虽然我们目前有 GIT_CONFIG_PARAMETERS 环境变量,可用于将运行时配置数据传递给 git 进程,但它是内部实现细节,不应由最终用户使用。
除了仅供内部使用之外,这种传递配置条目的方式还有一个主要缺点:需要解析配置键,因为它们在单个变量中包含键和值。
因此,留给用户对值中任何可能有害的字符进行转义,如果值由第三方控制,则很难做到这一点。
因此,此提交添加了一种通过环境添加配置条目的新方法,从而消除了此缺点。
如果用户传递了GIT_CONFIG_COUNT=$n 环境变量,Git 将为[0,n) 中的每个i 解析环境变量对GIT_CONFIG_KEY_$i 和GIT_CONFIG_VALUE_$i。
虽然git -c <name>=<value>(man) 可以实现相同的效果,但对于潜在的敏感信息可能不希望这样做。
例如
如果想将http.extraHeader 设置为包含身份验证令牌,则通过-c 这样做会轻易地通过例如泄漏这些凭据。 ps(1),通常还显示命令参数。
git config 现在包含在其man page 中:
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_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