Git handling of commit times

Grzegorz Junka list1 at
Thu May 30 02:34:56 UTC 2019

On 29/05/2019 19:27, Ed Maste wrote:
> On Wed, 29 May 2019 at 13:58, Grzegorz Junka <list1 at> wrote:
>> You mean undesirable cases? Since it's only metadata for git, these are
>> not invalid per se.
> Not invalid from the perspective of the Git DAG, but from the
> perspective of causality and time. Yes, the git client will allow me
> to create a commit dated next week (as it should). That said it'd be
> just fine for the server to refuse to accept such a commit on the
> basis that it's not actually valid.
>>> - commit time is later than the (accurate) server time
>> That would require a trip over the internet from a hook. Still doable
>> but not very user-friendly (as I mentioned earlier).
> Yes, this would have to be done on the server side. But, I don't think
> it's unfriendly for the server to deny a commit based on that commit
> reportedly happening in the future.

That's not what I was referring to.

The time when the commit is made is not related to when it's pushed to 
the remote. I am saying that for this to work the hook on your laptop 
would need to check the time on the server when the commit is being made 
locally (e.g. on a train).

The commit could be made, say, with tomorrow's date, but pushed to the 
remote next week. This would be invalid according to your definition 
(commit made with future date) but still wouldn't be caught (because 
it's pushed after that future date). Equally, the commit could be made 
with yesterday's date and if HEAD is a week ago this again wouldn't be 

 From what I understand you want to catch a situation when developer's 
VM was sleeping and then used to commit changes. In that case the local 
date will be behind the server's time, not ahead.

In any case, if you want to ensure that the timestamp in the commit when 
it's made locally (on your laptop) makes sense in the context of the 
server's time, then there is no other way than to check server time when 
the commit is being made, not when it's beings pushed. Or am I 
misunderstanding the requirements?

>> However, hooks may
>> be per branch, so checking time with the server could be done only for
>> example when merging/committing to a particular branch (e.g. so that
>> someone could commit without restrictions on their branch but when
>> merging with upstream branch the local time would be enforced to be
>> matched with the server time).
> Yeah, in this discussion I'm assuming that any such checks are
> performed only on the canonical repository, which likely holds only
> "official" branches. Forks and derived repositories are free to apply
> whatever commit hooks they see fit (or not).

Same story as above, I was referring to commits being made locally (on 
your laptop). Checking anything on the server is too late. Imagine that 
by accident you committed locally changes with yesterday's date (VM was 
sleeping) and now server rejects your push. In order to fix this you 
need to either:

1. Adjust your local time, set environment variables to the time you 
want to change, then rebase affected commits on top of the last commit 
that the server wouldn't reject (how to find it is another story). If 
any of those rebased commits have already been pushed then you suddenly 
have conflicts that you need to resolve by pulling remote changes, 
merging and pushing again.

2. Revert X commits up to the commit that the server wouldn't reject. 
Changed files should be in git staging now. Then you need to update the 
time and commit the files again. If you made 10 commits with proper 
commit messages then all this history is lost. After reverting you have 
all the changes in all the commits in git staging and now you can only 
commit the files once. Situation becomes more complicated if there was a 
merge within those commits that you reverted because the staging will 
contain all changes from all reverted commits. If you had any merge 
conflicts you will no longer have the history how these conflicts have 
been resolved, which will impact any future debugging of problems 
possibly caused by those commits.

Either situation is super user unfriendly. If you want to prevent 
incorrect timestamp then it must be done when the commit is being made 
locally, not on the server when the commit is being pushed from laptop 
to the remote repo. Of course you can do both but in my opinion just 
doing it on the server isn't enough.

More information about the freebsd-git mailing list