Re: [PATCH] commit: warn when a new commit is dated before its parent

[Junio C Hamano <gitster@pobox.com>]

"Devi Srinivas Vasamsetti via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Devi Srinivas Vasamsetti <devisrinivas.vasamsetti@gmail.com>
>
> Git writes whatever the clock says into the commit object. This can
> be problematic because history traversal assumes commit dates are
> non-decreasing. For example, "git log --since" stops walking at the
> first commit older than the cutoff, so an out-of-order date hides
> the commits behind it.

It might be annoying, but the value of such a warning is unclear.
If you clone from an upstream repository, you might find that the
commit at the tip was made on a machine with a clock set far in the
future.  When you try to make a commit on top of it, what are you
supposed to do?  Wait for a year so your commit is newer than the
tip?  Ask the committer to correct their clock, redo the commit, and
force-push?

It also does not help if the commit at the tip of the cloned branch
has a timestamp in the past, but is a child of a commit with an
incorrect timestamp.  Nobody would receive a warning, yet --since
may still stop prematurely.

Stepping back a bit, suppose you clone from upstream and obtain a
HEAD dated 24 hours ago, HEAD~1 dated 72 hours ago, and HEAD~2 dated
48 hours ago.  A command like git log --since=50.hours may stop
without showing HEAD~2, but if you suspect that some clocks are
skewed, there is no way to determine the correct output from these
timestamps anyway.  It is possible that HEAD~1 has an incorrect
timestamp and was actually written 30 hours ago, meaning all three
commits should be shown.  Alternatively, HEAD~2 might have an
incorrect timestamp and was written 80 hours ago, in which case
showing neither HEAD~1 nor HEAD~2 is correct.

The moral of the story is that --since or any other time-based
option cannot be fully reliable, as you cannot force everyone to
run with a correctly synchronized clock.  If you truly need to
know the ancestral relationship between commits, you should avoid
these options and use topology-based ones instead.