Git handling of commit times

[Grzegorz Junka]

On 30/05/2019 13:34, Ed Maste wrote:
> On Wed, 29 May 2019 at 22:34, Grzegorz Junka <list1 at gjunka.com> wrote:
>> 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).
> Yes, the commit time is not related to when it's pushed. But you still
> don't need any external access at the time of commit; perhaps I've
> been unclear about requirements. The goal here is to ensure that
> timestamp ordering matches commit DAG ordering, not that the
> timestamps are "correct" for some definition thereof.
>
> Let me try to clarify the two example cases:
>
>> The commit could be made, say, with tomorrow's date, but pushed to the
>> remote next week.
> That case is fine - if you have a post-dated commit that's not yet
> part of the canonical tree there's no issue; it's not possible for
> someone else to create another commit as a child of yours. The
> discussion here is about the view of commit dates in the canonical
> repository and a potential commit hook to enforce rules on those; it
> does not matter at all what's in a private repo.

I see. To reiterate, the aim is:

1. for each commit's timestamp to be later than timestamps of all its 
parents
2. for the server to only accept commits with timestamps earlier than 
its local time

Is that correct?


Imagine that I've been implementing new features and made 100 commits in 
my branch. I haven't noticed that my time may be incorrect (in the 
future). I pull remote branch and update my branch with latest changes:

git fetch
git pull remote_branch

No complains so far. The merge commit may be in the future, say a week 
later than remote_branch/HEAD, but it's still later than their parent, 
so it's OK. Now I want to push. But a hook on the server complains that 
I can't because my HEAD is later than their local time. Now what?

I agree that you can create a hook to ensure a timestamp in every commit 
is later than the timestamp in its parent commit(s). I am only arguing 
that it may negatively impact user experience if another hook doesn't 
ensure that local time matches remote time at the time local commit is 
being made. And that's difficult and another burden because it would 
require internet connection.

Besides, how often do you think it will happen that local time suddenly 
went backward and the hook would be triggered?


>> Equally, the commit could be made
>> with yesterday's date and if HEAD is a week ago this again wouldn't be
>> caught.
> That's fine too - as long as the commit is after its parents it's fine.

The canonical way of working with commits in git is by their hashes, not 
timestamps. If you, say, need to know amount of commits since a 
particular date, you first find a specific commit then use its hash in 
any git commands.

As you know the history in git is made of chains of commits. When 
branches are merged, their histories are joined in a merge commit, but 
it doesn't mean that the history becomes linear. Github and git log will 
show the history in a linear fashion without branches. But if you "git 
log --graph" you still see separate histories per branch as they were 
before they have been merged. If some today's commit was made with 
tomorrow's date it will be shown on that list after other commits in 
other branches committed today.

However, even if a commit has a timestamp that is later than the merge 
commit, it will still be shown before that merge commit. Git will 
respect the order of hashes in the first place, then the order of 
timestamps.

So, without any hooks commits would still be shown in the correct order, 
only date-related git query may not always return absolutely correct 
data. Is it worth the effort? Just treat timestamps as indicative and 
all problems are gone. Alternatively a hook can only warn user when the 
local clock doesn't seem to be correct without treating it as an error. 
If a developer can correct the situation, they should. If not, well, 
life isn't perfect.

GrzegorzJ