git日志没有按时间顺序排列

Question

我意外地发现，在一个公共项目(B2G，又名FirefosOS)中，git日志输出没有按时间顺序排列：

$ 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)             

一个年长的人怎么可能会在最近的一个人面前？

这种行为也可以在web接口：https://git.mozilla.org/?p=releases/gecko.git;a=log;h=refs/heads/master上观察到。

提前谢谢。

编辑:真正的问题是:提交(d4bb883)的提交日期如何可能比其直接父(5f3a596)更早？我可以断言它是直系亲属，因为有-图选项.

Answer 1

来自git日志的文档

-图 在输出的左侧绘制基于文本的提交历史记录的图形表示。这可能会导致在提交之间打印额外的线条，以便正确绘制图形历史记录。 ..。 --在默认情况下，这意味着--topo-order选项，但是-日期顺序选项也可能被指定.

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

-拓扑级 在向其所有子程序显示之前不显示父级，并避免在混合的多行历史上显示提交。 例如，在这样的提交历史记录中： -1-1 其中数字表示提交时间戳的顺序，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日志，所以更新的提交总是排序在它们的子级下面。因此，如果您有一个较早的提交(它是一个较新的提交的子项)，它将显示较旧的提交高于更新的提交。

但这怎么会发生呢？怎么可能提交(d4bb883)的提交日期比它的直接父节点更早？父母不一定要先被认出来吗？好吧，提交时间戳只是git添加到提交中的元数据，而且由于git的分布式特性，没有什么阻止提交人在创建提交时设置他们想要的日期。事实上，git重碱甚至有一些选项可以显式地允许您在提交日期方面“撒谎”：

--committer-date-is-author-date --ignore-date 将这些标志传递给git，以方便地更改重基提交的日期(请参阅git-am[1])。

博士说：

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

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

Answer 2

他们有可能使用某种类型的审查系统(例如这样的审查系统：格瑞特)。因此，较旧的提交可能需要更长的审核时间，因此合并需要更长的时间。

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