Git handling of commit times

[Grzegorz Junka]

On 29/05/2019 14:41, Ed Maste wrote:
> On Tue, 28 May 2019 at 23:20, Devin Teske <dteske at freebsd.org> wrote:
>>> Did anyone ever find an elegant solution to preventing the following edge-case?
>>>
>>> 1. Committer uses a VM but keeps it paused most of the time
>>>
>>> 2. Committer unpauses VM and makes a commit without first running ntpdate to correct the clock of the paused VM
>>>
>>> 3. Committer pushes commit with a timestamp that predates the timestamp for the previous commit on the file in-question
>>>
>>> In this case, GitHub renders the commits our of order. If memory serves, "git log" will show them in the proper order, but github web interface shows them in wrong order.


GitHub is the worst way of looking at commit history. Any other way is 
better than their clunky interface. The issue is that the history isn't 
linear no matter what you see in the interface. You either need to use 
Insights/Network or "git log --graph" to make sense of the order of commits.

Timestamp alone doesn't give much information. What matters is when the 
branch in which the commit was added has been merged with other branches 
(shown as merge commits in the history).


> It seems to me there are two separate issues here - committing with an
> incorrect system time, and GitHub's rendering. We should try to avoid
> the first case (e.g., by hooking into VM infrastructure to have the
> date set correctly after resume) where we can. I haven't actually
> checked GitHub's ordering.
>
> Git tracks the author and commit timestamps separately. They're often
> the same (e.g. if I commit a change and push it to a repository) but
> don't have to be - for example, if I cherry-pick change from someone
> the author time will be when they originally wrote it, while the
> commit time will be the time of my cherry-pick.
>
> There are other cases where the author time of a pair of changes will
> be out of order with respect to the commit ordering of those changes
> -- I may have a change to a file in my tree that I haven't pushed
> anywhere yet. If you then make a change to that file and I rebase, my
> change will come after in the commit graph but will have an earlier
> author time.
>
>>> I think there was some talk of a hook to prevent timestamps moving backward with respect to each object being touched in a pushed commit -- is this even possible to prevent?
> I believe a hook that prevents commit times from going backwards or
> being ahead of the server time would serve this purpose, but I haven't
> investigated in any detail. I'm also not sure off hand how GitHub,
> git, and other tools use author vs commit dates. This is something
> else that will need more investigation.


Bear in mind that commits are local (by the virtue of git being 
distributed scm). You can certainly write a git hook that verifies local 
time to be approximately the same as server time and stop the commit if 
that's not the case. But that's clunky and patronizing in my opinion 
(e.g. someone won't be able to commit when on a train and off the grid).

Also, when a developer wants to push local changes to the remote server, 
they have to pull remote first. That means a merge of remote branch with 
local branch. That merge, again, will be according to local time, which 
may be incorrect. When such a commit is pushed to the remote it may 
appear out of order in relation to other commits.

Git commits are joined by hashes, timestamp is only some metadata. It 
makes sens to talk about amount of commits since a particular hash but 
not so much about amount of commits since a particular date.

GrzegorzJ