git log 修订范围给出了不正确的提交范围

Question

我正在尝试使用 git log 的参数列出分支上给定范围内的所有提交。 .出于某种原因，它似乎没有给我正确的结果(或者我可能理解错了命令？)。

这是我正在做的步骤:

克隆 repo
git clone https://github.com/openstack/nova.git

做 git log这些是最后 9 次提交:

d5bde44 Merge "Make metadata password routines use Instance object"
6cbc9ee Merge "Fix object change detection"
39b7875 Merge "Fix object leak in nova.tests.objects.test_fields.TestObject"
94d1034 Merge "maint: correct docstring parameter description"
6407f17 Merge "Fix live_migration method's docstring"
7406661 Merge "Fix infinitely reschedule instance due to miss retry info"
9d8a34f Merge "Remove unused code from test_compute_cells"
429cd4b Fix object change detection
01381b8 Fix object leak in nova.tests.objects.test_fields.TestObject
...

假设我想在 01381b8 之后开始所有提交.我发出 git log 01381b8..HEAD可以看到以下输出:

d5bde44 Merge "Make metadata password routines use Instance object"
6cbc9ee Merge "Fix object change detection"
39b7875 Merge "Fix object leak in nova.tests.objects.test_fields.TestObject"
94d1034 Merge "maint: correct docstring parameter description"
6407f17 Merge "Fix live_migration method's docstring"
7406661 Merge "Fix infinitely reschedule instance due to miss retry info"
9d8a34f Merge "Remove unused code from test_compute_cells"
429cd4b Fix object change detection
2214bc0 Remove unused code from test_compute_cells
9639b55 Fix infinitely reschedule instance due to miss retry info
a5184d3 Fix live_migration method's docstring
76729a3 maint: correct docstring parameter description
28224a6 Make metadata password routines use Instance object

哇!我实际上得到了 13 当我预期时提交该输出 8 .这里发生了什么？修订范围是在给定提交后获取显示提交的正确机制吗？或者这是一个错误？

Answer 1

这里的问题在于“之后”的模糊概念。

提交与其说是“嵌入在图表中”，不如说是“之前”和“之后”。在这种情况下，由于存储库是可克隆的，所以我克隆了它。显然它相当活跃:

$ git log --oneline -9
77bad25 Merge "Remove deprecated config option names: Juno Edition"
d4d712a Merge "Deprecate instance_get_by_uuid() from conductor"
d5bde44 Merge "Make metadata password routines use Instance object"
6cbc9ee Merge "Fix object change detection"
39b7875 Merge "Fix object leak in nova.tests.objects.test_fields.TestObject"
94d1034 Merge "maint: correct docstring parameter description"
6407f17 Merge "Fix live_migration method's docstring"
7406661 Merge "Fix infinitely reschedule instance due to miss retry info"
9d8a34f Merge "Remove unused code from test_compute_cells"

这比您的 last-9 输出更新。然而，更有趣的是，如果它们用 --graph 记录，它们会是什么样子。添加(我会将数字增加到 10):

$ git log --oneline --graph -n 10

*   77bad25 Merge "Remove deprecated config option names: Juno Edition"
|\  
| * d0a02fa Remove deprecated config option names: Juno Edition
* |   d4d712a Merge "Deprecate instance_get_by_uuid() from conductor"
|\ \  
| * | 1d340cc Deprecate instance_get_by_uuid() from conductor
* | |   d5bde44 Merge "Make metadata password routines use Instance object"
|\ \ \  
| |/ /  
| * | 28224a6 Make metadata password routines use Instance object
* | |   6cbc9ee Merge "Fix object change detection"
|\ \ \  
| * | | 429cd4b Fix object change detection
* | | |   39b7875 Merge "Fix object leak in nova.tests.objects.test_fields.TestO
|\ \ \ \  
| |/ / /  
| * | | 01381b8 Fix object leak in nova.tests.objects.test_fields.TestObject

(我们得到一组不同的“最高”提交，因为 --graph 修改了遍历，这就是我进行 10 次提交的原因)。

要了解这里发生了什么，您需要超越 git log至 git rev-list .像许多 git 命令一样， git log用途 git rev-list选择要显示的修订。 (一些 git 命令实际上运行 git rev-list 而其他人共享其源代码，但无论哪种方式都一样。)

git 修订符号 x..y是 ^x y 的简写(或 y ^x——这些意思是一样的)。是否写了像 master这样的名字或 origin/stable/havana ，或间接名称，如 HEAD ，或原始提交 ID，或缩短的原始提交 ID，如 77bad25 , x和 y部分被解析为底层的 git 对象(在我们的例子中应该是一个提交)。您可以使用 git rev-parse 观察解析步骤。 :

$ git rev-parse master
77bad252096f7a4a8174340f0f2a3baf1fd52195
$ git rev-parse HEAD
77bad252096f7a4a8174340f0f2a3baf1fd52195
$ git rev-parse origin/stable/havana
0bf0bb4b5df64f7266c903a986d0b90a1f223822

什么 git rev-list这样做是从这个提交向后工作以找到它的父提交，然后从这些提交到他们的 parent ，依此类推。结果是一个祖先集。
master的祖先在这一点上，没有特定的顺序:

master本身:77bad25...

master的第一个 parent ，git rev-parse master^1 :d4d712a...

master的第二个 parent ，git rev-parse master^2 :d0a02fa...

master的第一个 parent 的第一个 parent ，git rev-parse master^1^1 :d5bde44...

master的第一个 parent 的第二个 parent ，git rev-parse master^1^2 :1d340cc...

当然还有更多，返回许多提交:

$ git rev-list master | wc -l
   27918

所以 git rev-list master选择所有 2.7 万次提交，以及 git log master将向您显示所有这些(以某种顺序，根据通过 git rev-list 传递给 git log 的附加选项修改顺序)。

要排除其中一些，您可以告诉 git rev-list从一些特定的修订开始——例如 01381b8 ——并找到它的所有祖先(包括 01381b8 本身):

$ git rev-list 01381b8 | wc -l
   27901

在这一点上，这比从 master 开始发现的提交少 17 次。并向后工作(并且第二个列表中没有第一个列表中没有的提交)。所以如果你告诉 git rev-list为了给你“从 master 开始的所有提交，减去从 01381b8 开始的所有提交”，你应该得到 17 个提交:

$ git rev-list master ^01381b8 | wc -l
      17

事实上，这就是我们所看到的。 (实际列表并不是那么有趣，但您可以使用 git rev-list master ^01381b8 或等效的 git rev-list 01381b8..master 看到它。)

这些提交是 git log将显示给你，给定相同的修订范围。

您可以花几天时间研究 git rev-list文档和仍然遗漏项目(例如， --graph 告诉你它“启用父重写”和“暗示 --topo-order”，直到我刚才检查，我忘记了父重写部分。幸运的是，这不适用于这里无论如何，只需要 --date-order 强制图形版本按日期而不是拓扑排序。)