git - git name-rev 有什么作用？

Question

根据 git name-rev doc ,

Finds symbolic names suitable for human digestion for revisions given in any format parsable by git rev-parse.

但我无法理解这一点。这个命令有什么用？和 git describe有什么区别命令 ？我认为 两者也做同样的事情 - 给一个 SHA1 Id，给我们返回最接近它的引用名称？

Answer 1

Marek R's answer是正确的，但有点不完整。

本质上，git name-rev想出一个名字加上一些相对表达式，如果需要，从名字移动到提交，而 git describe想出一些名称——通常是标签名称，但也可能是其他名称——如果需要，再加上一些额外的字符串，这不是特别“相对”:在某些情况下有一个计数，但它不如计数那么有用在 git name-rev .如 git describe无法使用原始名称，它添加了 g和一个缩写的哈希 ID:

$ git describe
v2.19.1-272-gf84b9b09d4

但:

$ git name-rev HEAD
HEAD master

如果我们添加 --all至 git describe的参数， git describe确实使用分支名称，但输出不同:

$ git describe --all
heads/master

特别要注意的是它使用了分支名称，因为如果分支名称和标签名称之间存在冲突——如果存在 refs/tags/master以及—解析 master单独生成与标签关联的哈希 ID，而不是分支名称。

除此之外， git describe可以加 -dirty如果工作树与提交不匹配，并且——从 Git 2.16.0 开始——可以产生 name:pathname string 为您提供一个命名特定存储 blob 的表达式:

$ git describe HEAD:Makefile
v2.19.0-237-ge3d4ff037d:Makefile

这不是什么 git name-rev可以管理。

目的不同

What is the use of [git name-rev]?

我从未真正见过有人自己使用它，但请参见下文。先从 git describe的目的说起: git describe非常常用来生成特定构建的有用描述。因为它默认只使用标签，所以它的输出相对稳定(好吧，如果我们假设标签永远不会改变的话)。当 git describe说 v2.19.1-272-gf84b9b09d4 ， 我们知道:

提交发生在 v2.19.1 之后的一段时间

实际提交的哈希 ID 以 f84b9b09d4 开头

和 future git describe同一提交的输出可能是相同的(尽管如果我们添加一个新的带注释的标签，它们可能会改变)。可通过 v2.19.1..f84b9b09d4 获得的 272 次提交的计数:

$ git rev-list --count v2.19.1..f84b9b09d4
272

不会改变。运行 git rev-parse v2.19.1-272-gf84b9b09d4将始终产生 f84b9b09d40408cf91bbc500d9f190a7866c3e0f ，不管我明天还是下周还是明年再做，只要标记 v2.19.1留在原地。如果我们使用这个字符串作为构建标识符，我们避免使用分支名称并注意构建是否“脏”，我们可以立即判断我们是否可以在以后轻松地再次重现相同的构建，如果是，如何(即，通过运行 git checkout v2.19.1-272-gf84b9b09d4 )。

另一方面，当 git name-rev说 master或 master~3或者无论如何，不​​能保证我明天可以回到那个存储库并使用相同的表达式来找到相同的提交。明年，它几乎可以肯定是错误的。所以 git name-rev输出仅适用于一小段时间——基本上，直到您移动一些分支名称。

同时， git name-rev有一个技巧， git describe不会:它会解析它的标准输入，寻找看起来是哈希 ID 的东西。当它找到它们时，它会将它们复制到标准输出并添加  (expression) ，前提是哈希转换为名称:

$ X=$(git rev-parse master)
$ echo embedded $X hash | git name-rev --stdin
embedded f84b9b09d40408cf91bbc500d9f190a7866c3e0f (master) hash
$ Y=$(echo $X | sed s/f/0/)
$ echo embedded invalid $Y hash | git name-rev --stdin
embedded invalid 084b9b09d40408cf91bbc500d9f190a7866c3e0f hash

这意味着您可以，如文档中所示，运行 git log | git name-rev并让所有这些提交哈希成为装饰哈希。但是，散列必须是完整的散列。相比:

$ git log --oneline -n 10 | git name-rev --stdin
f84b9b09d4 Sync with 2.19.1
cae598d998 Git 2.19.1
1958ad504b Sync with 2.18.1
268fbcd172 Git 2.18.1
44f87dac99 Sync with 2.17.2
6e9e91e9ca Git 2.17.2
1a7fd1fb29 fsck: detect submodule paths starting with dash
a124133e1e fsck: detect submodule urls starting with dash
e43aab778c Sync with 2.16.5
27d05d1a1a Git 2.16.5

和:

$ git log --pretty=tformat:'%H %s' -n 10 | git name-rev --stdin
f84b9b09d40408cf91bbc500d9f190a7866c3e0f (master) Sync with 2.19.1
cae598d9980661a978e2df4fb338518f7bf09572 (tags/v2.19.1^0) Git 2.19.1
1958ad504befa6a09c475cc8ab9de43b359de137 (tags/v2.19.1~1) Sync with 2.18.1
268fbcd172cdb306e8a3e7143cc16677c963d6cd (tags/v2.18.1^0) Git 2.18.1
44f87dac99574a8073ffb1ba8b10bd4d3945f61b (tags/v2.18.1~1) Sync with 2.17.2
6e9e91e9cae74cd7feb9300563d40361b2b17dd2 (tags/v2.17.2^0) Git 2.17.2
1a7fd1fb2998002da6e9ff2ee46e1bdd25ee8404 (tags/v2.17.2~1) fsck: detect submodule paths starting with dash
a124133e1e6ab5c7a9fef6d0e6bcb084e3455b46 (tags/v2.17.2~2) fsck: detect submodule urls starting with dash
e43aab778c72250e11eb00e31dc6be90072a1637 (tags/v2.17.2~3) Sync with 2.16.5
27d05d1a1a62273aa3749f4d0ab8a126ef11ff66 (tags/v2.16.5^0) Git 2.16.5

底线:使用最适合您特定目的的那个。哪一个取决于你的目的是什么。