Git handling of commit times

[Ed Maste]

On Wed, 29 May 2019 at 17:26, Warner Losh <imp at bsdimp.com> wrote:
>
> The very simple work flow of
>
> git branch -b foo
> hack
> git commit
> <time passes>
> git checkout master
> git pull
> git rebase -i master foo
> <repeat sequence>
>
> would setup a situation where commits are in the past. By default, rebase commits don't have their timestamps reset.

Rebasing does reset the commit timestamp (and not the author
timestamp). I don't think we should impose any constraints on author
timestamps in a Git workflow. But these two things should be
invariants: the commit timestamp of a change is not earlier than any
of its parents, and the commit timestamp is not later than now.

> Also, resetting the time changes the hash of the commit, iirc.

Yes, changing anything in the state of the tree or the commit's
metadata will change the hash. (Notes are not included in this.)

> Depends on how far in the future. Time is an illusion. git commit time doubly so :) But this assumes that all the world's clocks are in sync, and they are not. minutes of difference often exist. it's a royal pita to be on the wrong side of the sync when pushing commits upstream to a server you have no control over the time of.

I'd hope we can be reasonably sure about the time on (say)
git.freebsd.org, but point taken. Perhaps something like "not more
than 1 minute in the future, relative to the server's clock."