I'm seeing this on this GitHub repository:
What does this mean? How can something be "authored 7 days ago", and yet "committed 14 hours ago"?
2 Answers
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 <[email protected]>
AuthorDate: Tue Nov 18 14:52:49 2014 -0200
Commit: Thiago Pontes <[email protected]>
CommitDate: Tue Nov 25 09:46:58 2014 -0200
open repository url if confirmed, closes #1
-
1
git rebasealso causes the commit date to be updated while the author date remains the same.– cjmCommented Nov 26, 2014 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.– SchwernCommented Nov 26, 2014 at 18:59
-
1
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.
answered Nov 26, 2014 at 2:40
-
2While 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.– SchwernCommented Nov 26, 2014 at 8:21
-
2Committing 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.– ADTCCommented Nov 27, 2014 at 0:47
commit --date=. Schwern explains it very nicely.