git log not chronologically ordered

Question

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 ?

This behaviour may also be observed on the web interface : https://git.mozilla.org/?p=releases/gecko.git;a=log;h=refs/heads/master

Thanks in advance.

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.

Answer 1

From the documentation for git log:

--graph

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.

[...]

This implies the --topo-order option by default, but the --date-order option may also be specified.

And if we look at the documentation for the --topo-order option:

--topo-order

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

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.

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.

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.

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:

--committer-date-is-author-date

--ignore-date

These flags are passed to git am to easily change the dates of the rebased commits (see git-am[1]).

And git-am's docs say:

--committer-date-is-author-date

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.

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.