Git日志未按时间顺序排序

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)             

如何让一个较旧的提交在最近的提交前面呢？

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

提前感谢。

编辑：真正的问题是：如何可能一次提交（d4bb883）比它的直接父提交（5f3a596）具有更早的提交日期？我可以通过 --graph 选项断言它是直接父提交。

- fgdfgdfgdsg

---

你应该编辑你的问题，突出显示你正在使用--graph、--all和commit日期显示。 - Bastien

Answer 1

来自git log文档：

--graph

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

[...]

默认情况下会启用--topo-order选项，但也可以指定--date-order选项。

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

--topo-order

在显示所有子代之前不显示任何父代，并避免显示交错的多行历史提交。

例如，在类似以下的提交历史中：

---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甚至有选项可以明确允许您“欺骗”提交日期：

--committer-date-is-author-date

--ignore-date

这些标志被传递给git am，以便轻松更改rebased提交的日期（请参见git-am[1]）。

git-am的文档还说：

--committer-date-is-author-date

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

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

- Ajedi32

---

感谢您详细的回答。 - fgdfgdfgdsg

Answer 2

他们可能使用某种审查系统（例如Gerrit），因此较旧的提交可能需要更长时间进行审查，因此需要更长时间才能合并。

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

- Zelardiel