Git handling of commit times
list1 at gjunka.com
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 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.
>>> - 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