commit: warn when a new commit is dated before its parent

From: Yashwanth Sai <[email protected]>

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.

The check looks at the commit being created and its parents and nothing else. Skew between different machines is ordinary in a distributed system and is not something to complain about; this fires only when one repository's own history steps backwards. It is limited to git commit -- merges and replayed history go through other paths, where non-monotonic dates are often legitimate.

A warning along these lines has been suggested more than once without landing; see for instance the discussion around clock skew in <CA+55aFw_XjWm+4XwsN6CRJnsrcEu5YEChOHSHN51UUBN6PynWw@mail.gmail.com>.

---
commit: warn when a new commit is dated before its parent

This is an RFC: a warning of this shape has been suggested more than once over the years without landing, so I would rather learn whether it is wanted at all before polishing it.

The reproduction that motivated it -- a commit inside the window is silently skipped because traversal stops at an out-of-order parent:

$ 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 missing. This is understood -- 96697781e0 (revision: add "--since-as-filter" option, 2022-07-19) added an opt-in traversal mode for exactly it -- but nothing tells the person whose clock caused it, at the point where it is still cheap to fix. I hit this on a repository of my own after moving the system clock to test date-dependent behaviour; by the time I noticed, the dates were part of the object names.

What the warning looks like:

hint: the new commit is dated 2026-09-13 06:00:00 +0530,
hint: which is earlier than its parent, dated 2026-09-25 10:00:00 +0000.
hint: This usually means the system clock is wrong.
hint: Commands that walk history in date order, such as
hint: "git log --since", may skip commits as a result.
hint: Disable this message with "git config set advice.clockSkew false"

The scope is deliberately narrow:

* Warn, never refuse. Only the committer can tell whether their clock or the parent's is the wrong one.
* The commit being created and its parents, nothing else. Skew between machines is ordinary in a distributed system; this fires only when one repository's own history steps backwards.
* git commit only. Merges and replayed history go through other paths, where non-monotonic dates are frequently legitimate.

Questions I would most like answered:

1. Is this wanted at all? Both conclusions -- that it is a good idea, and that it may not be worth the effort -- appear in the archives.

2. Is advice the right channel? There is a fair objection that hints on stderr get buried among other output.

3. Should fsck grow an INFO-tier check for the "far ahead of now" case too? That cannot compare against parents, since fsck_commit() deliberately never loads parent objects, so it would be a separate and weaker check.

t7502 gains three tests; t7502, t7501, t7500 and t0018 all pass.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2226%2Fysai258%2Fadvice-clock-skew-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2226/ysai258/advice-clock-skew-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2226

 Documentation/config/advice.adoc |  7 ++++
 advice.c                         |  1 +
 advice.h                         |  1 +
 builtin/commit.c                 | 61 ++++++++++++++++++++++++++++++++
 t/t7502-commit-porcelain.sh      | 27 ++++++++++++++
 5 files changed, 97 insertions(+)

index 81f80a9274..59b643d9d0 100644
@@ -38,6 +38,13 @@ all advice messages.
 		configuration variable for how to set a given remote
 		to be used by default in some situations where this
 		advice would be printed.
+	clockSkew::
+		Shown by linkgit:git-commit[1] when the commit being
+		created is dated earlier than one of its parents, which
+		usually means the system clock is wrong. History
+		traversal assumes commit dates do not decrease, so such
+		a commit can cause commands like `git log --since` to
+		skip the commits behind it.
 	commitBeforeMerge::
 		Shown when linkgit:git-merge[1] refuses to
 		merge to avoid overwriting local changes.

index 63bf8b0c5f..3e14859de4 100644
@@ -50,6 +50,7 @@ static struct {
 	[ADVICE_AMBIGUOUS_FETCH_REFSPEC]		= { "ambiguousFetchRefspec" },
 	[ADVICE_AM_WORK_DIR] 				= { "amWorkDir" },
 	[ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME] 	= { "checkoutAmbiguousRemoteBranchName" },
+	[ADVICE_CLOCK_SKEW]				= { "clockSkew" },
 	[ADVICE_COMMIT_BEFORE_MERGE]			= { "commitBeforeMerge" },
 	[ADVICE_DEFAULT_BRANCH_NAME]			= { "defaultBranchName" },
 	[ADVICE_DETACHED_HEAD]				= { "detachedHead" },

index 66f6cd6a77..43de2b19a2 100644
@@ -17,6 +17,7 @@ enum advice_type {
 	ADVICE_AMBIGUOUS_FETCH_REFSPEC,
 	ADVICE_AM_WORK_DIR,
 	ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME,
+	ADVICE_CLOCK_SKEW,
 	ADVICE_COMMIT_BEFORE_MERGE,
 	ADVICE_DEFAULT_BRANCH_NAME, /* To be retired sometime after Git 3.0 */
 	ADVICE_DETACHED_HEAD,

index 2adfe70b3d..fb611b191b 100755
@@ -1003,4 +1003,31 @@ test_expect_success WITH_BREAKING_CHANGES 'core.commentChar=auto is rejected' '
 	test_cmp expect actual
 '
 
+test_expect_success 'warn when a commit is dated before its parent' '
+	test_when_finished "git checkout main 2>/dev/null || git checkout master" &&
+	git checkout -b clock-skew &&
+	test_commit --date "2026-09-25T10:00:00+0000" skew-parent &&
+	echo skew >skew-child &&
+	git add skew-child &&
+	GIT_COMMITTER_DATE="2026-09-13T06:00:00+0000" \
+		git commit -m "behind its parent" 2>actual &&
+	test_grep "earlier than its parent" actual
+'
+
+test_expect_success 'no warning when commit dates increase' '
+	echo forward >skew-forward &&
+	git add skew-forward &&
+	GIT_COMMITTER_DATE="2026-09-26T06:00:00+0000" \
+		git commit -m "after its parent" 2>actual &&
+	test_grep ! "earlier than its parent" actual
+'
+
+test_expect_success 'advice.clockSkew silences the warning' '
+	echo quiet >skew-quiet &&
+	git add skew-quiet &&
+	GIT_COMMITTER_DATE="2026-09-14T06:00:00+0000" \
+		git -c advice.clockSkew=false commit -m quiet 2>actual &&
+	test_grep ! "earlier than its parent" actual
+'
+
 test_done

base-commit: 47ce80527c56f462cb97db4ca8125342204d3783

gitgitgadget

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

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

Thanks for looking at it, and for the pointer.

You're right. I hadn't read the AI section of SubmittingPatches before sending, and I should have. The patch was written with AI assistance to the extent that I can't honestly claim it as my own work under the DCO, so I'm withdrawing it. I've closed the pull request.

Sorry for the noise. If I come back to this, I'll write it myself.

Yours Sincerely,
M Yashwanth Sai
9491363067