Git handling of commit times

[Warner Losh]

On Wed, May 29, 2019 at 12:27 PM Ed Maste <emaste at freebsd.org> wrote:

> On Wed, 29 May 2019 at 13:58, Grzegorz Junka <list1 at gjunka.com> 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.
>

I think this is not a viable position to stake out.

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. This means that you can have
commits in any sort of weird order, and they can be days, weeks, months
even years in the past depending on how long the branch took to develop.
Nobody sees this today because people using git svn have the timestamp
reset when pushing to svn because there's no notion of setting a time on
the commit. Also, resetting the time changes the hash of the commit, iirc.

Now, this isn't the 'next week' case, but it shows that trying to be too
pedantic about this will lead to issues.

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

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.


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

This bit is wise.

Warner