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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

On 2026-09-19 at 14:04:25, Yashwanth Sai via GitGitGadget wrote:
> From: Yashwanth Sai <ysaimuppineni789@gmail.com>
> 
> Git writes whatever the clock says into the commit object and validates
> nothing: a commit dated years in the future, or earlier than its own
> parent, is accepted silently. "git fsck --strict" does not object either,
> since fsck's badDate and badDateOverflow checks are purely syntactic.
> 
> That would be harmless if history traversal did not assume commit dates
> are non-decreasing, but it does. "git log --since" stops walking at the
> first commit older than the cutoff, so a single out-of-order date hides
> every commit behind it:
> 
> 	$ git log --pretty='%cd %s' --date=short
> 	2026-09-25 C3 - inside the window
> 	2026-09-01 C2 - outside the window
> 	2026-09-20 C1 - inside the window
> 
> 	$ git log --pretty='%cd %s' --date=short --since=2026-09-13
> 	2026-09-25 C3 - inside the window
> 
> C1 is inside the window and silently missing. This is understood --
> 96697781e0 (revision: add "--since-as-filter" option, 2022-07-19) added
> an opt-in traversal mode for it -- but nothing tells the person whose
> clock caused it, at the moment they could still fix it cheaply.
> 
> Warn at commit time when the new commit's date precedes a parent's, gated
> on a new advice.clockSkew setting. Warning rather than refusing is
> deliberate: only the committer can tell whether their clock or the
> parent's is the wrong one. Once the commit is published the date is part
> of its object name, and correcting it means rewriting every descendant,
> so the warning is worth little later and quite a lot now.

I think such a change is useful and it certainly has been discussed on
the list quite a bit.

> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

I don't think this is allowed by the `ai` section of
`Documentation/SubmittingPatches`. I wouldn't be opposed to seeing such
a patch if it were not produced in any way by AI, though.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]