2

I'm looking at this commit which was committed "26 days ago" and the parent commit which was committed "25 days ago". How can the parent commit be committed one day later than the child commit?

  • Local timezone? – coredump Apr 5 '16 at 5:34
  • @coredump I don't see how timezone can affect this because I'm looking at the time shown in github page, which must be on the same timezone – Can't Tell Apr 5 '16 at 5:39
  • The local time is used and stored in the resulting commit. The information does not change anymore after and does not depend on how you look at it. I did not investigate, but the authors of the two commits are different. After all, it is possible to fabricate commits with different dates, using the --date option. – coredump Apr 5 '16 at 6:08
1

Git distinguishes between authoring a change (actually writing the code in the change) and committing a change (adding the change to the repository), and tracks both the author and committer, as well as the authoring date and commit date separately. Imagine, for example, someone sending you a patch by email: she is the author, you are "just" the committer.

So, it might be that GitHub shows the authoring date instead of the commit date (after all, that's the more interesting information if you want to find it where the source code came from) and that the commit in question was created from a patch authored before the parent commit was committed. Git shows the author data by default (and fills in the values from the commit data if missing).

In addition, Git allows you to override the commit date.

Example for both:

git init

msg='a regular commit'
GIT_COMMITTER_DATE=2011-01-01T00:00:00Z git commit --allow-empty -m"$msg"

msg='commit with author date set before the commit but after parent'
GIT_COMMITTER_DATE=2012-01-01T00:00:00Z git commit --date=2011-07-01T00:00:00Z --allow-empty -m"$msg"

msg='commit with author date set before parent'
GIT_COMMITTER_DATE=2013-01-01T00:00:00Z git commit --date=2011-12-01T00:00:00Z --allow-empty -m"$msg"

msg='commit with commit date set before parent'
GIT_COMMITTER_DATE=2012-07-01T00:00:00Z git commit --allow-empty -m"$msg"

git log

# commit deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# Author: Joe Random Developer <joe@example.com>
# Date:   Tue Apr 5 10:33:10 2016 +0200
# 
#     commit with commit date set before parent
# 
# commit deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# Author: Joe Random Developer <joe@example.com>
# Date:   Thu Dec 1 00:00:00 2011 +0000
# 
#     commit with author date set before parent
# 
# commit deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# Author: Joe Random Developer <joe@example.com>
# Date:   Fri Jul 1 00:00:00 2011 +0000
# 
#     commit with author date set before the commit but after parent
# 
# commit deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# Author: Joe Random Developer <joe@example.com>
# Date:   Tue Apr 5 10:33:10 2016 +0200
# 
#     a regular commit
# 
  • Occam's Razor says the more likely cause is that the computers used to create these commits had clocks that were out of sync. Not everybody uses NTP. – kdgregory Apr 5 '16 at 10:43
  • The commit in question is part of a pull request, IIRC GitHub uses cherry-picking sometimes in handling pull requests, which would lead to a new commit being created with metadata from the old commit. Considering that the pull request was created before the commit which would then later become the parent, but was merged after, it is not inconceivable that GitHub would have created a new commit after the parent which has its metadata still set to the original metadata, i.e. before the parent. – Jörg W Mittag Apr 5 '16 at 10:50
1

The most likely cause is that the developer of the second commit rebased his/her branch from master before merging.

Here's a series of commands that will reproduce (the branch command is an alias that will either switch to an existing branch or create a new one; the master command switches to master):

1   mkdir /tmp/$$
2   cd /tmp/$$
3   git init
4   touch foo
5   git add foo
6   git commit -m "initial commit" foo
7   branch bar
8   touch bar
9   git add bar
10  git commit -m "add bar"
11  master
12  vi foo
13  git commit -m "first change" foo
14  git log
15  branch bar
16  git rebase master
17  git log

And here's the output of the log:

commit 61f2fe8360ceeee15f97b47204ed3205342d1b10
Author: Keith Gregory <redacted>
Date:   Tue Apr 5 06:46:05 2016 -0400

    add bar

commit 6240517ac68610b7b4f7cd72f1a0508b20d2c220
Author: Keith Gregory <redacted>
Date:   Tue Apr 5 06:46:46 2016 -0400

    first change

commit ae094204b813ae217fd74a640634c7e82ecb4732
Author: Keith Gregory <redacted>
Date:   Tue Apr 5 06:45:51 2016 -0400

    initial commit

If you use the cat-file command, you can see that commit 62 is indeed the parent of 61:

> git cat-file -p 61f2fe8360ceeee15f97b47204ed3205342d1b10

tree b8300b3b463ee72eb18f78d6602e0274087597d1
parent 6240517ac68610b7b4f7cd72f1a0508b20d2c220
author Keith Gregory <contact@kdgregory.com> 1459853165 -0400
committer Keith Gregory <contact@kdgregory.com> 1459853233 -0400

It's also entirely possible that the clocks on the two developers' workstations were out of sync. Github doesn't touch the commits at all, so will use whatever time the committer specified in their commit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.