Git handling of commit times
list1 at gjunka.com
Thu May 30 18:12:52 UTC 2019
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
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 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
> 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
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.
More information about the freebsd-git