Question

我在一个公共项目（B2G又名FirefosOS）上意外地发现git log输出没有按时间顺序排列：

$ git clone https://git.mozilla.org/releases/gecko.git
$ git log --graph --format='%C(yellow)%h%Creset %cr %C(blue)%<(7,trunc)%cn%Creset -%C(auto)%d%Creset %<(80,trunc)%s' --all

* da7ef8a 74 minutes ago B2G B.. - (origin/v2.1) Bumping manifests a=b2g-bump                                                    
* ccf235d 83 minutes ago B2G B.. - Bumping gaia.json for 1 gaia revision(s) a=gaia-bump                            
* 653f117 7 hours ago B2G B.. - Bumping manifests a=b2g-bump                                                    
* cc5501b 7 hours ago B2G B.. - Bumping gaia.json for 2 gaia revision(s) a=gaia-bump                            
* b4a22de 13 hours ago B2G B.. - Bumping manifests a=b2g-bump                                                    
* 4ad0ee9 13 hours ago B2G B.. - Bumping gaia.json for 2 gaia revision(s) a=gaia-bump                            
* 6390e1b 14 hours ago B2G B.. - Bumping manifests a=b2g-bump                                                    
* 9c57530 14 hours ago B2G B.. - Bumping gaia.json for 2 gaia revision(s) a=gaia-bump                            
* 07e2a96 3 weeks ago Hsin-.. - Bug 1096128 - [B2G][STK] support call number modified by STK call control. r=a..
* 49daf73 3 weeks ago Fredr.. - Bug 1091601 - Settings closes down when changing permissions for THA applicati..
* d4bb883 3 weeks ago Rober.. - Bug 1073252. Fix bustage in part 4, a=bajaj                                     
* 5f3a596 2 days ago B2G B.. - Bumping manifests a=b2g-bump                                                    
* 79bdd97 2 days ago B2G B.. - Bumping gaia.json for 1 gaia revision(s)

旧的提交怎么可能在最近的提交之前呢？

也可以在网络界面上观察到此行为：https://git.mozilla.org/?p=releases/gecko.git;a=log;h=refs/heads/master

提前致谢。

编辑：真正的问题是：如果提交（d4bb883）的提交日期比其直接父级（5f3a596）更早？由于--graph选项，我可以断言它是直接父级。

Answer 1

来自the documentation for git log：

<强> - 图

在输出的左侧绘制提交历史的基于文本的图形表示。这可能会导致在提交之间打印额外的行，以便正确绘制图表历史记录。

[...]

这意味着默认情况下使用--topo-order选项，但也可以指定--date-order选项。

如果我们查看--topo-order选项的文档：

<强> - TOPO-顺序

在显示所有子项之前不显示父项，并避免在多行历史记录中混合显示提交。

例如，在这样的提交历史中：
---1----2----4----7
    \              \
     3----5----6----8---
其中数字表示提交时间戳的顺序，git rev-list和--date-order的朋友按时间戳顺序显示提交：8 7 6 5 4 3 2 1.

--topo-order，他们会显示8 6 5 3 7 4 2 1（或8 7 4 2 6 5 3 1）;为了避免将两个平行开发轨道的提交混合在一起，显示了一些较旧的提交在新的提交之前。

因为你正在使用带有--graph的git log，所以新的提交总是在他们的孩子下面订购。因此，如果您的旧提交是较新提交的子项，则git log --graph将在较新提交之上显示旧提交。

但这怎么可能发生？提交（d4bb883）的提交日期可能比其直接父级更早？父母不必先被提交吗？好吧，提交时间戳只是通过git添加到提交的元数据，并且由于git的分布式特性，没有什么能阻止提交者在他们创建的提交上设置他们想要的任何日期。事实上，git rebase甚至还有明确允许你“欺骗”的选项。关于提交日期：

<强> - 提交者-日期是-作者 - 日期

<强> - 忽略-日期

这些标志传递给git am以轻松更改已重新提交的提交的日期（请参阅git-am[1]）。

git-am's docs说：

<强> - 提交者-日期是-作者 - 日期

默认情况下，该命令将电子邮件中的日期记录为提交作者日期，并使用提交创建时间作为提交者日期。 这允许用户使用与作者日期相同的值来说谎提交者日期。

除了--committer-date-is-author-date之外，还有其他方法可以错误地设置提交日期，例如在提交者的PC上设置错误的系统时钟。关键是，提交者日期不一定总是准确的。

Answer 2

他们可能会使用某种审核系统（此类审核系统的示例：Gerrit）。因此，较旧的提交可能会在审核时间较长，因此合并需要更长的时间。

因此，较新的提交可能会更快合并。

git log没有按时间顺序排列

2 个答案: