From: Junio C Hamano Date: Tue, 06 Oct 2026 14:37:27 GMT Subject: Re: [PATCH] commit: warn when a new commit is dated before its parent Message-ID: In-Reply-To: "Devi Srinivas Vasamsetti via GitGitGadget" writes: > From: Devi Srinivas Vasamsetti > > 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.