Git handling of commit times

Ed Maste emaste at
Thu May 30 18:30:09 UTC 2019

On Thu, 30 May 2019 at 14:12, Grzegorz Junka <list1 at> wrote:
> 1. for each commit's timestamp to be later than timestamps of all its
> parents
> 2. for the server to only accept commits with timestamps earlier than
> its local time
> Is that correct?

Presumably, yes, and this is all in order to address dteske's concern
about misordering when rendering changes. Note also that (2) is not a
requirement per se but instead imposed by (1) (otherwise, someone may
make an "in the future" commit which then prevents someone else from
making a commit with the "correct" time).

> Imagine that I've been implementing new features and made 100 commits in
> my branch. I haven't noticed that my time may be incorrect (in the
> future). I pull remote branch and update my branch with latest changes:
> git fetch
> git pull remote_branch
> No complains so far. The merge commit may be in the future, say a week
> later than remote_branch/HEAD, but it's still later than their parent,
> so it's OK. Now I want to push. But a hook on the server complains that
> I can't because my HEAD is later than their local time. Now what?

Correct the clock, and do the rebase or merge (but critically, not the
actual commits) again. Enable ntpd or clock-refresh-after-resume or
etc. on the client to avoid issues next time.

> I agree that you can create a hook to ensure a timestamp in every commit
> is later than the timestamp in its parent commit(s). I am only arguing
> that it may negatively impact user experience if another hook doesn't
> ensure that local time matches remote time at the time local commit is
> being made. And that's difficult and another burden because it would
> require internet connection.

This whole issue is a bit off in the weeds, since it's really a
discussion about a way to prevent a hypothetical case that might
affect the way commits are ordered/rendered by certain tools. And
while I agree this may have a small negative impact on user experience
I think it's fairly easy to recover from.

We could also look at extending the communication with the server (for
'git fetch') and produce a warning if the local time is appreciably
different from the server, with a goal of prodding the user into
fixing it earlier.

> Besides, how often do you think it will happen that local time suddenly
> went backward and the hook would be triggered?

IMO it would happen very rarely - so if it does solve a rendering
issue (with GitHub, etc.) and almost never triggers it seems like it
wouldn't be much of a burden.

More information about the freebsd-git mailing list