Git handling of commit times

Warner Losh imp at
Thu May 30 02:28:30 UTC 2019

On Wed, May 29, 2019 at 8:18 PM Ed Maste <emaste at> wrote:

> On Wed, 29 May 2019 at 17:26, Warner Losh <imp at> 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.

How do I see this other timestamp. git log doesn't show it by default,
hence the basis of my views...

> > 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)
>, but point taken. Perhaps something like "not more
> than 1 minute in the future, relative to the server's clock."

I have no clue what the time on is, nor do I know if it is
sane or not in the face of all kinds of crazy stuff, including leap
seconds, bad configuration, active attack, clock steps because someone[tm]
though a different ntp daemon would be good enough and didn't understand
all the nuanced differences? How sure can we really be about the time on in the face of enemy action, perhaps designed to prevent
commits from happening for a period of time to prevent an exploit fix from
being committed?

Maybe I'm being too paranoid. Lord knows I spent a decade in the time and
frequency business worrying about all these sorts of things, but many of
the worries were, frankly, due to the weak time handling in edge cases in
ntpd. So long as we can get a cryptographic sync of, or get
one of the time and frequency companies too donate a stratum 1 GPS
receiver + kit (their cheapest one will likely do fine), then we're golden.
Otherwise it gets weird since ntp is basically an unauthenticated protocol
unless you can jump through the right hoops...

Again, don't mean to sound alarmist, but if we're going to enforce time
synchronization, we'd better have a high assurance of no monkey business


More information about the freebsd-git mailing list