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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2026, 14:37 UTC
Message-ID: <xmqqld8agajc.fsf@gitster.g>
In-Reply-To: <pull.2235.git.1791212998072.gitgitgadget@gmail.com>

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

Show 7 quoted lines

> 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.