git-describe
的典型输出看起来像
some-tag-32-gf31f980
其中
some-tag
是标签名称,32
表示所描述的提交是使用该标签提交后的 32 次提交,gf31f980
表示提交 ID 唯一缩写为 f31f980
。
我的问题是关于
g
中的gf31f980
。为什么它在那里?我的第一个想法是插入它是为了消除对 git-describe
输出的解析的歧义。但我想不出在任何情况下拥有它确实有帮助。例如,可能会省略 32
组件,并且无法知道上面的输出描述的是标签 some-tag
之后 32 次提交,而不是标签 some-tag-32
处的提交 at。但
g
对此没有帮助。
仅提取提交 ID 的正则表达式匹配可以搜索
/-g([0-9a-f]+)$/
。没有简单的方法可以简化这个过程;例如,您不能执行 /-g(.*)$/
,因为这可能会错误地匹配标签名称中的 g
。如果没有 g
,您仍然可以执行 /-([0-9a-f]+)$/
,因此 g
无法帮助您。非正则表达式解析过程的行为类似。
g
是显式生成的;相关源代码(builtin/describe.c
第240行左右)是:
static void show_suffix(int depth, const unsigned char *sha1)
{
printf("-%d-g%s", depth, find_unique_abbrev(sha1, abbrev));
}
很难搜索到这方面的信息,因为相关术语
g
是一个停用词。
g
有什么用?
Jesse Luehrs 立即在 Twitter 上指出,这个问题在
git-describe
手册页中得到了解答:
“g”前缀代表“git”,是 用于允许根据软件所在的 SCM 来描述软件的版本 管理与。
在 Git 2.33(2021 年第 3 季度)中,“
-g
”前缀有更多内容(已在 Git v1.1.0,提交 908e531,2005 年 12 月: 中引入)
请参阅 Anders Höckersten (ahockersten
)
的commit bfe35a6(2021 年 5 月 17 日)。
gitster
-- 合并于 commit d8c6dc2,2021 年 6 月 10 日)
:澄清缩写的默认长度describe-doc
签署人:Anders Höckersten
澄清用于 git 描述中提交的缩写形式的默认长度。
该行为在 Git 2.11.0 中进行了修改,但未更新文档来阐明新行为。
git describe
现在包含在其 手册页中:
而不是使用默认的十六进制数字(即 将根据存储库中对象的数量而变化 默认值为 7) 缩写对象名称,使用
数字,或者 根据需要使用尽可能多的数字来形成唯一的对象名称。<n>
git describe
现在包含在其 手册页中:
哈希后缀是“-g”+提示提交的明确缩写 父母的(这是
)。这 缩写的长度随着存储库的增长而扩展,使用 存储库中对象的大致数量和一些数学知识 围绕生日悖论,默认为最小值 7。2414721b194453f058079d897d13c4e377f92dc6
如果
真的是为了消除 git 与其他 SCM 软件的歧义,那么输出的其他部分肯定也需要相同。不仅仅是提交 SHA 有所不同 - 另一个 SCM 可能根本不具有相同的标签,并且可能具有完全不同的提交数量。所以对我来说仍然显得毫无用处,尤其是在事情中间,融入得如此之好。g
g
前缀的主要目的不是在高层消除 Git 与其他 SCM 系统的歧义(例如,将 Git 标签与 Subversion 修订版或 Mercurial 变更集 ID 进行比较)。git-describe
输出用于各种上下文(例如软件版本控制、构建过程或文档)时,它有助于识别以下哈希是 Git 提交哈希。
g
充当 Git 版本控制方案的指示器,特别是在 Git 哈希值包含在软件工件的名称、标签或版本中的情况下。git-describe
输出保持清晰且明确,即使在自动解析场景中也是如此。
g
前缀充当额外的特异性层。在多个工具和版本控制方案可能交叉的复杂或自动化环境中,这有助于防止混淆并确保解析版本字符串的脚本或工具了解它们正在使用的标识符的性质。