git log未按时间顺序排列 [英] git log not chronologically ordered
问题描述
我在公共项目(B2G，又称FirefosOS)中意外发现git log输出未按时间顺序排列:
I found out unexpectedly on a public project (B2G aka FirefosOS) that git log output is not chronologically ordered :
$ 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)
较早的提交怎么可能在最近的提交之前?
How may an older commit be in front of an recent one ?
在网络界面上也可能会观察到此行为: https://git.mozilla.org/?p=releases/gecko.git;a=log;h=refs/heads/master
This behaviour may also be observed on the web interface : https://git.mozilla.org/?p=releases/gecko.git;a=log;h=refs/heads/master
谢谢.
真正的问题是:一个提交(d4bb883)的提交日期比其直接父提交(5f3a596)的提交日期怎么可能?由于--graph选项，我可以断言它是直接父级.
EDIT : the real question is : how is it possible that a commit (d4bb883) has older commit date than its direct parent (5f3a596) ? I can assert that it is the direct parent because of the --graph option.
推荐答案
来自 git日志的文档:
-图形
在输出的左侧绘制提交历史记录的基于文本的图形表示.这可能会导致在两次提交之间打印额外的行，以便正确绘制图形历史记录.
Draw a text-based graphical representation of the commit history on the left hand side of the output. This may cause extra lines to be printed in between commits, in order for the graph history to be drawn properly.
[...]
默认情况下，这意味着--topo-order选项，但是也可以指定--date-order选项.
This implies the --topo-order option by default, but the --date-order option may also be specified.
如果我们查看--topo-order选项的文档:
And if we look at the documentation for the --topo-order option:
-拓扑顺序
在显示所有子项之前不显示任何父母，并避免在多个历史记录中混合显示提交内容.
Show no parents before all of its children are shown, and avoid showing commits on multiple lines of history intermixed.
例如，在这样的提交历史中:
For example, in a commit history like this:
---1----2----4----7
\ \
3----5----6----8---
其中的数字表示提交时间戳的顺序，git rev-list和带有--date-order的朋友按时间戳顺序显示提交:8 7 6 5 4 3 2 1.
where the numbers denote the order of commit timestamps, git rev-list and friends with --date-order show the commits in the timestamp 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)；为了避免显示来自两个并行开发轨道的提交混合在一起，在更新的提交之前会显示一些较旧的提交.
With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 3 1); some older commits are shown before newer ones in order to avoid showing the commits from two parallel development track mixed together.
因此，因为您将git log与--graph一起使用，所以较新的提交始终在其子级之下排序.因此，如果您有一个较旧的提交，它是较新的提交的子项，则它git log --graph将在较新的提交上方显示较早的提交.
So because you are using git log with --graph, newer commits always ordered below their children. So if you have an older commit which is a child of a newer commit, it git log --graph will show the older commit above the newer one.
这怎么会发生?提交(d4bb883)的提交日期比其直接父提交日期更早的可能性如何?父母不必一定要先犯吗?好吧，提交时间戳只是git添加到提交中的元数据，由于git的分布式特性，没有什么可以阻止提交者在创建的提交中设置他们想要的任何日期.实际上， git rebase 甚至具有明确允许您说谎"提交日期的选项. :
How can this happen though? How is it possible that a commit (d4bb883) has an older commit date than its direct parent? Wouldn't the parent have to have to have been committed first? Well, commit timestamps are just metadata added to commits by git, and because of git's distributed nature there's nothing stopping committers from setting whatever date they want on the commits they create. In fact, git rebase even has options which explicitly allow you to "lie" about commit dates:
-提交者的日期是作者的日期
-忽略日期
这些标志会传递给git am，以轻松更改重新基于基础的提交的日期(请参见 git- am [1] ).
These flags are passed to git am to easily change the dates of the rebased commits (see git-am[1]).
-提交者的日期是作者的日期
默认情况下，该命令将电子邮件中的日期记录为提交作者日期，并使用提交创建的时间作为提交者日期. 这允许用户使用与作者日期相同的值来确定提交者的日期.
By default the command records the date from the e-mail message as the commit author date, and uses the time of commit creation as the committer date. This allows the user to lie about the committer date by using the same value as the author date.
除了--committer-date-is-author-date之外，还有其他错误设置提交日期的方法，例如错误地设置提交者PC的系统时钟.关键是，提交者的日期不一定总是准确的.
Aside from --committer-date-is-author-date though, there are other ways in which a commit date could be set incorrectly, such as an incorrectly set system clock on the committer's PC. The point is, committer dates won't necessarily always be accurate.
这篇关于git log未按时间顺序排列的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
