20

I'm seeing this on this GitHub repository:

enter image description here

What does this mean? How can something be "authored 7 days ago", and yet "committed 14 hours ago"?

  • Could git be measuring the timestamps between the files he edited and when he actually committed and pushed? I don't see a use for such a feature but that's kinda what the wording implies.. – Seth Nov 26 '14 at 2:24
  • @Seth That's what I thought at first, but I'd never even heard of Git doing anything with timestamps. – Undo Nov 26 '14 at 2:32
  • @Seth Git ignores file timestamps. The committer can alter author timestamp on-the-fly using commit --date=. Schwern explains it very nicely. – ADTC Nov 27 '14 at 0:41
  • @Undo I hope you are not confusing "14 hours ago" with "14 days ago"... Now that would be truly strange, to have something committed which apparently wasn't even authored yet until 7 days later... I'm not sure if Git prevents setting the author timestamp greater than committer timestamp; it probably doesn't care. – ADTC Nov 27 '14 at 0:52
20

Git has a separate concept of the author (the person who wrote the code) and committer (the person who committed it to the repository). Similarly there can be different dates for both. They are usually the same.

You'd want them to be different primarily if the person writing the code or submitting the patch does not have push access to the repository as in projects which use mailing lists for patch submissions. In this case, the person with push access would apply the patch and run git commit with either the --author and --date switches or using the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE environment variables (documented in git-commit-tree.

The other case is using git cherry-pick or git rebase. The committer is the person doing the the cherry pick, and the author is the author of the original commit. Git will handle setting the author identity and date for you.

You can see this information in the repository with git log --pretty=fuller.

commit 21550561941b078ea1862b882ec89f26696ff5bb (HEAD, origin/master, origin/HEAD, master)
Author:     thiagopnts <thiagopnts@gmail.com>
AuthorDate: Tue Nov 18 14:52:49 2014 -0200
Commit:     Thiago Pontes <email@thiago.me>
CommitDate: Tue Nov 25 09:46:58 2014 -0200

    open repository url if confirmed, closes #1
  • 1
    git rebase also causes the commit date to be updated while the author date remains the same. – cjm Nov 26 '14 at 17:27
  • @cjm You're right! rebase and cherry-pick both behave the same in this respect. That makes sense, a rebase can be thought of as multiple cherry-picks. – Schwern Nov 26 '14 at 18:59
  • 1
    For applying patches from mail, there's also git am, which automatically takes the date and author from the mail message. – deltab Nov 26 '14 at 20:50
6

This looks like a mix between how Git works with dates and how it was referenced with GitHub's closing keywords.

Git separates between commit and author dates. In Pro Git they go a bit into the difference:

The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit – you as the author, and the core member as the committer.

So while the code itself was committed/written "7 days ago" (locally), it wasn't "applied" or patched to the code until "14 hours ago", since it wasn't seen in the remote until that referenced close message.

  • 2
    While I haven't tested it, I do not believe the author information was added by Github closing keywords. The committer and author identities and dates are baked into the commit ID. If Github changed any of these it would change the commit ID on the remote end. The remote and local repositories would diverge. The author would be unable to push or pull without forcing it. – Schwern Nov 26 '14 at 8:21
  • 2
    Committing is not the same as pushing to remote. Remember that almost everything in Git can be done locally, including commits. You can commit first (which gives both timestamps) and push later (which merely uploads the commit to remote but doesn't give any timestamp). There is no 'push timestamp' as it's unimportant to know when a commit was pushed - it can be (and often is) pushed and pulled any number of times. – ADTC Nov 27 '14 at 0:47

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.