{"thread":{"id":"66352","subject":"[PATCH/RFC] commit: warn when a new commit is dated before its parent","startedAt":"2026-09-19T14:04:27Z","lastAt":"2026-09-19T15:47:15Z","messageCount":3,"participants":["Yashwanth Sai via GitGitGadget","brian m. carlson","Yashwanth Sai"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"552880","messageId":"pull.2226.git.1789826665188.gitgitgadget@gmail.com","threadId":"66352","inReplyTo":null,"subject":"[PATCH/RFC] commit: warn when a new commit is dated before its parent","fromName":"Yashwanth Sai via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-19T14:04:25Z","receivedAt":"2026-09-19T14:04:27Z","isPatch":true,"body":"From: Yashwanth Sai \n\nGit writes whatever the clock says into the commit object and validates\nnothing: a commit dated years in the future, or earlier than its own\nparent, is accepted silently. \"git fsck --strict\" does not object either,\nsince fsck's badDate and badDateOverflow checks are purely syntactic.\n\nThat would be harmless if history traversal did not assume commit dates\nare non-decreasing, but it does. \"git log --since\" stops walking at the\nfirst commit older than the cutoff, so a single out-of-order date hides\nevery commit behind it:\n\n\t$ git log --pretty='%cd %s' --date=short\n\t2026-09-25 C3 - inside the window\n\t2026-09-01 C2 - outside the window\n\t2026-09-20 C1 - inside the window\n\n\t$ git log --pretty='%cd %s' --date=short --since=2026-09-13\n\t2026-09-25 C3 - inside the window\n\nC1 is inside the window and silently missing. This is understood --\n96697781e0 (revision: add \"--since-as-filter\" option, 2022-07-19) added\nan opt-in traversal mode for it -- but nothing tells the person whose\nclock caused it, at the moment they could still fix it cheaply.\n\nWarn at commit time when the new commit's date precedes a parent's, gated\non a new advice.clockSkew setting. Warning rather than refusing is\ndeliberate: only the committer can tell whether their clock or the\nparent's is the wrong one. Once the commit is published the date is part\nof its object name, and correcting it means rewriting every descendant,\nso the warning is worth little later and quite a lot now.\n\nThe check looks at the commit being created and its parents and nothing\nelse. Skew between different machines is ordinary in a distributed system\nand is not something to complain about; this fires only when one\nrepository's own history steps backwards. It is limited to git commit --\nmerges and replayed history go through other paths, where non-monotonic\ndates are often legitimate.\n\nA warning along these lines has been suggested more than once without\nlanding; see for instance the discussion around clock skew in\n.\n\nCo-authored-by: Claude Opus 5 (1M context) \nSigned-off-by: Yashwanth Sai \n---\n commit: warn when a new commit is dated before its parent\n \n This is an RFC: a warning of this shape has been suggested more than\n once over the years without landing, so I would rather learn whether it\n is wanted at all before polishing it.\n \n The reproduction that motivated it -- a commit inside the window is\n silently skipped because traversal stops at an out-of-order parent:\n \n $ git log --pretty='%cd %s' --date=short\n 2026-09-25 C3 - inside the window\n 2026-09-01 C2 - outside the window\n 2026-09-20 C1 - inside the window\n \n $ git log --pretty='%cd %s' --date=short --since=2026-09-13\n 2026-09-25 C3 - inside the window\n \n \n C1 is inside the window and missing. This is understood -- 96697781e0\n (revision: add \"--since-as-filter\" option, 2022-07-19) added an opt-in\n traversal mode for exactly it -- but nothing tells the person whose\n clock caused it, at the point where it is still cheap to fix. I hit this\n on a repository of my own after moving the system clock to test\n date-dependent behaviour; by the time I noticed, the dates were part of\n the object names.\n \n What the warning looks like:\n \n hint: the new commit is dated 2026-09-13 06:00:00 +0530,\n hint: which is earlier than its parent, dated 2026-09-25 10:00:00 +0000.\n hint: This usually means the system clock is wrong.\n hint: Commands that walk history in date order, such as\n hint: \"git log --since\", may skip commits as a result.\n hint: Disable this message with \"git config set advice.clockSkew false\"\n \n \n The scope is deliberately narrow:\n \n * Warn, never refuse. Only the committer can tell whether their clock\n or the parent's is the wrong one.\n * The commit being created and its parents, nothing else. Skew between\n machines is ordinary in a distributed system; this fires only when\n one repository's own history steps backwards.\n * git commit only. Merges and replayed history go through other paths,\n where non-monotonic dates are frequently legitimate.\n \n Questions I would most like answered:\n \n 1. Is this wanted at all? Both conclusions -- that it is a good idea,\n and that it may not be worth the effort -- appear in the archives.\n \n 2. Is advice the right channel? There is a fair objection that hints on\n stderr get buried among other output.\n \n 3. Should fsck grow an INFO-tier check for the \"far ahead of now\" case\n too? That cannot compare against parents, since fsck_commit()\n deliberately never loads parent objects, so it would be a separate\n and weaker check.\n \n t7502 gains three tests; t7502, t7501, t7500 and t0018 all pass.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2226%2Fysai258%2Fadvice-clock-skew-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2226/ysai258/advice-clock-skew-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/2226\n\n Documentation/config/advice.adoc | 7 ++++\n advice.c | 1 +\n advice.h | 1 +\n builtin/commit.c | 61 ++++++++++++++++++++++++++++++++\n t/t7502-commit-porcelain.sh | 27 ++++++++++++++\n 5 files changed, 97 insertions(+)\n\ndiff --git a/Documentation/config/advice.adoc b/Documentation/config/advice.adoc\nindex 81f80a9274..59b643d9d0 100644\n--- a/Documentation/config/advice.adoc\n+++ b/Documentation/config/advice.adoc\n@@ -38,6 +38,13 @@ all advice messages.\n \t\tconfiguration variable for how to set a given remote\n \t\tto be used by default in some situations where this\n \t\tadvice would be printed.\n+\tclockSkew::\n+\t\tShown by linkgit:git-commit[1] when the commit being\n+\t\tcreated is dated earlier than one of its parents, which\n+\t\tusually means the system clock is wrong. History\n+\t\ttraversal assumes commit dates do not decrease, so such\n+\t\ta commit can cause commands like `git log --since` to\n+\t\tskip the commits behind it.\n \tcommitBeforeMerge::\n \t\tShown when linkgit:git-merge[1] refuses to\n \t\tmerge to avoid overwriting local changes.\ndiff --git a/advice.c b/advice.c\nindex 63bf8b0c5f..3e14859de4 100644\n--- a/advice.c\n+++ b/advice.c\n@@ -50,6 +50,7 @@ static struct {\n \t[ADVICE_AMBIGUOUS_FETCH_REFSPEC]\t\t= { \"ambiguousFetchRefspec\" },\n \t[ADVICE_AM_WORK_DIR] \t\t\t\t= { \"amWorkDir\" },\n \t[ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME] \t= { \"checkoutAmbiguousRemoteBranchName\" },\n+\t[ADVICE_CLOCK_SKEW]\t\t\t\t= { \"clockSkew\" },\n \t[ADVICE_COMMIT_BEFORE_MERGE]\t\t\t= { \"commitBeforeMerge\" },\n \t[ADVICE_DEFAULT_BRANCH_NAME]\t\t\t= { \"defaultBranchName\" },\n \t[ADVICE_DETACHED_HEAD]\t\t\t\t= { \"detachedHead\" },\ndiff --git a/advice.h b/advice.h\nindex 66f6cd6a77..43de2b19a2 100644\n--- a/advice.h\n+++ b/advice.h\n@@ -17,6 +17,7 @@ enum advice_type {\n \tADVICE_AMBIGUOUS_FETCH_REFSPEC,\n \tADVICE_AM_WORK_DIR,\n \tADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME,\n+\tADVICE_CLOCK_SKEW,\n \tADVICE_COMMIT_BEFORE_MERGE,\n \tADVICE_DEFAULT_BRANCH_NAME, /* To be retired sometime after Git 3.0 */\n \tADVICE_DETACHED_HEAD,\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 28f6174503..70b9aa5ec5 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -11,6 +11,7 @@\n #include \"builtin.h\"\n #include \"advice.h\"\n #include \"config.h\"\n+#include \"date.h\"\n #include \"lockfile.h\"\n #include \"cache-tree.h\"\n #include \"color.h\"\n@@ -21,6 +22,7 @@\n #include \"commit.h\"\n #include \"add-interactive.h\"\n #include \"gettext.h\"\n+#include \"ident.h\"\n #include \"revision.h\"\n #include \"wt-status.h\"\n #include \"run-command.h\"\n@@ -1666,6 +1668,63 @@ struct repository *repo UNUSED)\n \treturn 0;\n }\n \n+/*\n+ * Warn when the commit we are about to write is dated earlier than a parent.\n+ *\n+ * Git stores whatever the clock says, and history traversal assumes commit\n+ * dates do not decrease: \"git log --since\", for one, stops walking at the\n+ * first commit older than the cutoff, so an out-of-order date silently hides\n+ * the commits behind it. Only the person committing can tell whether their\n+ * clock or the parent's is the wrong one, so warn rather than refuse.\n+ *\n+ * This deliberately looks at nothing but the commit being created and its\n+ * parents. Skew between machines is normal in a distributed system and is not\n+ * something to complain about at commit time.\n+ */\n+static void warn_if_dated_before_parents(struct commit_list *parents)\n+{\n+\tstruct ident_split committer;\n+\tstruct strbuf ours = STRBUF_INIT;\n+\tconst char *info;\n+\ttimestamp_t date, newest = 0;\n+\n+\tif (!advice_enabled(ADVICE_CLOCK_SKEW))\n+\t\treturn;\n+\n+\tinfo = git_committer_info(IDENT_STRICT);\n+\tif (split_ident_line(&committer, info, strlen(info)) ||\n+\t !committer.date_begin)\n+\t\treturn;\n+\tdate = parse_timestamp(committer.date_begin, NULL, 10);\n+\n+\tfor (; parents; parents = parents->next) {\n+\t\tstruct commit *parent = parents->item;\n+\n+\t\tif (repo_parse_commit(the_repository, parent))\n+\t\t\tcontinue;\n+\t\tif (parent->date > newest)\n+\t\t\tnewest = parent->date;\n+\t}\n+\n+\tif (!newest || date >= newest)\n+\t\treturn;\n+\n+\t/* show_date() reuses one buffer, so keep a copy of the first result. */\n+\tstrbuf_addstr(&ours, show_date(date, atoi(committer.date_end + 1),\n+\t\t\t\t DATE_MODE(ISO8601)));\n+\n+\tadvise_if_enabled(ADVICE_CLOCK_SKEW,\n+\t\t\t _(\"the new commit is dated %s,\\n\"\n+\t\t\t \"which is earlier than its parent, dated %s.\\n\"\n+\t\t\t \"This usually means the system clock is wrong.\\n\"\n+\t\t\t \"Commands that walk history in date order, such as\\n\"\n+\t\t\t \"\\\"git log --since\\\", may skip commits as a result.\"),\n+\t\t\t ours.buf,\n+\t\t\t /* A parsed commit keeps no timezone, so show UTC. */\n+\t\t\t show_date(newest, 0, DATE_MODE(ISO8601)));\n+\tstrbuf_release(&ours);\n+}\n+\n static int git_commit_config(const char *k, const char *v,\n \t\t\t const struct config_context *ctx, void *cb)\n {\n@@ -1935,6 +1994,8 @@ int cmd_commit(int argc,\n \t\tappend_merge_tag_headers(parents, &tail);\n \t}\n \n+\twarn_if_dated_before_parents(parents);\n+\n \tif (commit_tree_extended(sb.buf, sb.len, &the_repository->index->cache_tree->oid,\n \t\t\t\t parents, &oid, author_ident.buf, NULL,\n \t\t\t\t sign_commit, extra)) {\ndiff --git a/t/t7502-commit-porcelain.sh b/t/t7502-commit-porcelain.sh\nindex 2adfe70b3d..fb611b191b 100755\n--- a/t/t7502-commit-porcelain.sh\n+++ b/t/t7502-commit-porcelain.sh\n@@ -1003,4 +1003,31 @@ test_expect_success WITH_BREAKING_CHANGES 'core.commentChar=auto is rejected' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'warn when a commit is dated before its parent' '\n+\ttest_when_finished \"git checkout main 2>/dev/null || git checkout master\" &&\n+\tgit checkout -b clock-skew &&\n+\ttest_commit --date \"2026-09-25T10:00:00+0000\" skew-parent &&\n+\techo skew >skew-child &&\n+\tgit add skew-child &&\n+\tGIT_COMMITTER_DATE=\"2026-09-13T06:00:00+0000\" \\\n+\t\tgit commit -m \"behind its parent\" 2>actual &&\n+\ttest_grep \"earlier than its parent\" actual\n+'\n+\n+test_expect_success 'no warning when commit dates increase' '\n+\techo forward >skew-forward &&\n+\tgit add skew-forward &&\n+\tGIT_COMMITTER_DATE=\"2026-09-26T06:00:00+0000\" \\\n+\t\tgit commit -m \"after its parent\" 2>actual &&\n+\ttest_grep ! \"earlier than its parent\" actual\n+'\n+\n+test_expect_success 'advice.clockSkew silences the warning' '\n+\techo quiet >skew-quiet &&\n+\tgit add skew-quiet &&\n+\tGIT_COMMITTER_DATE=\"2026-09-14T06:00:00+0000\" \\\n+\t\tgit -c advice.clockSkew=false commit -m quiet 2>actual &&\n+\ttest_grep ! \"earlier than its parent\" actual\n+'\n+\n test_done\n\nbase-commit: 47ce80527c56f462cb97db4ca8125342204d3783\n-- \ngitgitgadget\n"},{"id":"552883","messageId":"aq6j2yg16L2iNHoR@fruit.crustytoothpaste.net","threadId":"66352","inReplyTo":"pull.2226.git.1789826665188.gitgitgadget@gmail.com","subject":"Re: [PATCH/RFC] commit: warn when a new commit is dated before its parent","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-09-19T15:01:48Z","receivedAt":"2026-09-19T15:10:15Z","isPatch":true,"body":"On 2026-09-19 at 14:04:25, Yashwanth Sai via GitGitGadget wrote:\n> From: Yashwanth Sai \n> \n> Git writes whatever the clock says into the commit object and validates\n> nothing: a commit dated years in the future, or earlier than its own\n> parent, is accepted silently. \"git fsck --strict\" does not object either,\n> since fsck's badDate and badDateOverflow checks are purely syntactic.\n> \n> That would be harmless if history traversal did not assume commit dates\n> are non-decreasing, but it does. \"git log --since\" stops walking at the\n> first commit older than the cutoff, so a single out-of-order date hides\n> every commit behind it:\n> \n> \t$ git log --pretty='%cd %s' --date=short\n> \t2026-09-25 C3 - inside the window\n> \t2026-09-01 C2 - outside the window\n> \t2026-09-20 C1 - inside the window\n> \n> \t$ git log --pretty='%cd %s' --date=short --since=2026-09-13\n> \t2026-09-25 C3 - inside the window\n> \n> C1 is inside the window and silently missing. This is understood --\n> 96697781e0 (revision: add \"--since-as-filter\" option, 2022-07-19) added\n> an opt-in traversal mode for it -- but nothing tells the person whose\n> clock caused it, at the moment they could still fix it cheaply.\n> \n> Warn at commit time when the new commit's date precedes a parent's, gated\n> on a new advice.clockSkew setting. Warning rather than refusing is\n> deliberate: only the committer can tell whether their clock or the\n> parent's is the wrong one. Once the commit is published the date is part\n> of its object name, and correcting it means rewriting every descendant,\n> so the warning is worth little later and quite a lot now.\n\nI think such a change is useful and it certainly has been discussed on\nthe list quite a bit.\n\n> Co-authored-by: Claude Opus 5 (1M context) \n\nI don't think this is allowed by the `ai` section of\n`Documentation/SubmittingPatches`. I wouldn't be opposed to seeing such\na patch if it were not produced in any way by AI, though.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"552887","messageId":"CABykktEd-rn04SeFQqqpnB0npDaSxVLx5vQ1f9LmJGJpVckv6w@mail.gmail.com","threadId":"66352","inReplyTo":"aq6j2yg16L2iNHoR@fruit.crustytoothpaste.net","subject":"Re: [PATCH/RFC] commit: warn when a new commit is dated before its parent","fromName":"Yashwanth Sai","fromEmail":"ysaimuppineni789@gmail.com","sentAt":"2026-09-19T15:46:37Z","receivedAt":"2026-09-19T15:47:15Z","isPatch":true,"body":"Thanks for looking at it, and for the pointer.\n\nYou're right. I hadn't read the AI section of SubmittingPatches before\nsending, and I should have. The patch was written with AI assistance to\nthe extent that I can't honestly claim it as my own work under the DCO,\nso I'm withdrawing it. I've closed the pull request.\n\nSorry for the noise. If I come back to this, I'll write it myself.\n\n\nOn Sat, Sep 19, 2026 at 8:32 PM brian m. carlson\n wrote:\n>\n> On 2026-09-19 at 14:04:25, Yashwanth Sai via GitGitGadget wrote:\n> > From: Yashwanth Sai \n> >\n> > Git writes whatever the clock says into the commit object and validates\n> > nothing: a commit dated years in the future, or earlier than its own\n> > parent, is accepted silently. \"git fsck --strict\" does not object either,\n> > since fsck's badDate and badDateOverflow checks are purely syntactic.\n> >\n> > That would be harmless if history traversal did not assume commit dates\n> > are non-decreasing, but it does. \"git log --since\" stops walking at the\n> > first commit older than the cutoff, so a single out-of-order date hides\n> > every commit behind it:\n> >\n> > $ git log --pretty='%cd %s' --date=short\n> > 2026-09-25 C3 - inside the window\n> > 2026-09-01 C2 - outside the window\n> > 2026-09-20 C1 - inside the window\n> >\n> > $ git log --pretty='%cd %s' --date=short --since=2026-09-13\n> > 2026-09-25 C3 - inside the window\n> >\n> > C1 is inside the window and silently missing. This is understood --\n> > 96697781e0 (revision: add \"--since-as-filter\" option, 2022-07-19) added\n> > an opt-in traversal mode for it -- but nothing tells the person whose\n> > clock caused it, at the moment they could still fix it cheaply.\n> >\n> > Warn at commit time when the new commit's date precedes a parent's, gated\n> > on a new advice.clockSkew setting. Warning rather than refusing is\n> > deliberate: only the committer can tell whether their clock or the\n> > parent's is the wrong one. Once the commit is published the date is part\n> > of its object name, and correcting it means rewriting every descendant,\n> > so the warning is worth little later and quite a lot now.\n>\n> I think such a change is useful and it certainly has been discussed on\n> the list quite a bit.\n>\n> > Co-authored-by: Claude Opus 5 (1M context) \n>\n> I don't think this is allowed by the `ai` section of\n> `Documentation/SubmittingPatches`. I wouldn't be opposed to seeing such\n> a patch if it were not produced in any way by AI, though.\n> --\n> brian m. carlson (they/them)\n> Toronto, Ontario, CA\n\n\n\n-- \nYours Sincerely,\nM Yashwanth Sai\n9491363067\n"}]}