Git handling of commit times

Ed Maste emaste at
Wed May 29 18:27:51 UTC 2019

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.

> 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).

More information about the freebsd-git mailing list