{"thread":{"id":"66722","subject":"[PATCH] describe: count the distance correctly when commit dates are skewed","startedAt":"2026-10-31T06:55:03Z","lastAt":"2026-11-04T18:29:27Z","messageCount":17,"participants":["Linus Torvalds","Tuomas Ahola","Junio C Hamano","SZEDER Gábor","Patrick Steinhardt","Derrick Stolee","Kristofer Karlsson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"556992","messageId":"20261031065525.19883-2-torvalds@kernel.org","threadId":"66722","inReplyTo":null,"subject":"[PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Linus Torvalds","fromEmail":"torvalds@kernel.org","sentAt":"2026-10-31T06:55:03Z","receivedAt":"2026-10-31T06:55:03Z","isPatch":true,"sender":{"key":"torvalds@kernel.org","avatar":null},"body":"From: Linus Torvalds \n\nThe current merge window for Linux v7.4 showed annoying behavior with\n'git describe', where it doesn't actually follow the documented intent\nof the result: the commit distance is miscomputed when the commit dates\naren't entirely reliable.\n\nThis makes the 'git describe' output not match what the kernel\ncalculates in its localversion:\n\n\tlinux$ git describe && uname -r\n\tv7.3-19342-g2a500a04d6f9\n\t7.3.0-19059-g2a500a04d6f9\n\nand the kernel calculation is correct, and 'git describe' is wrong. The\nnumber that 'git describe' gives (19342) is nonsense.\n\nThe reason is that 'git describe' has walked the commit list past the\nactual tagged release due to walking the commits purely in date order,\nand is thus counting a few hundred commits that were already included in\nLinux 7.3.\n\nThe fix is to take the commit generation number into account when\nordering the commits. That will still fail if the repository has no\ncommit graph, but it at least improves on the situation in the common\ncase. With that one-liner fix, 'git describe' gets the correct commit\ndistance on my kernel tree:\n\n\tlinux$ git describe && uname -r\n\tv7.3-19059-g2a500a04d6f9\n\t7.3.0-19059-g2a500a04d6f9\n\nSee also commit 1b600e659a (\"Compute accurate distances in git-describe\nbefore output.\", 2007-01-27) which fixed a different issue in this same\narea. Clearly the *intent* is that the distance number is actually the\nreal distance.\n\nAlso add a test-case for this. Thanks to Claude.\n\nSigned-off-by: Linus Torvalds \n---\n\n[ Using my kernel.org email to send this, because setting that up is\n easier than fighting gmail .. - Linus ]\n\n builtin/describe.c | 2 +-\n t/t6120-describe.sh | 27 +++++++++++++++++++++++++++\n 2 files changed, 28 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/describe.c b/builtin/describe.c\nindex c0abc931a5..2cd597d919 100644\n--- a/builtin/describe.c\n+++ b/builtin/describe.c\n@@ -328,7 +328,7 @@ static void append_suffix(int depth, const struct object_id *oid, struct strbuf\n static void describe_commit(struct commit *cmit, struct strbuf *dst)\n {\n \tstruct commit *c, *gave_up_on = NULL;\n-\tstruct prio_queue queue = { compare_commits_by_commit_date };\n+\tstruct prio_queue queue = { compare_commits_by_gen_then_commit_date };\n \tstruct commit_name *n;\n \tstruct possible_tag all_matches[MAX_TAGS];\n \tunsigned int match_cnt = 0, annotated_cnt = 0, cur_match;\ndiff --git a/t/t6120-describe.sh b/t/t6120-describe.sh\nindex 7a7c46658a..a75f9227d9 100755\n--- a/t/t6120-describe.sh\n+++ b/t/t6120-describe.sh\n@@ -749,6 +749,33 @@ test_expect_success 'setup: describe commits with disjoint bases 2' '\n check_describe -C disjoint2 \"B-3-gHASH\" HEAD\n check_describe -C disjoint2 --expect-failure \"B-3-gHASH\" --candidates=2 HEAD\n \n+# T\n+# o----o----o----x\n+# \\ /\n+# `--o--'\n+# B\n+#\n+# T is dated an hour before its parent, so a walk by commit date\n+# reaches T's parent through B before it reaches T.\n+#\n+test_expect_success 'setup: describe a tag dated before its parent' '\n+\tgit init skew &&\n+\t(\n+\t\tcd skew &&\n+\t\tgit config core.commitGraph true &&\n+\t\ttest_commit --date \"2020-01-01 18:00\" base &&\n+\t\ttest_commit --date \"2020-01-01 18:01\" o &&\n+\t\ttest_commit --annotate --date \"2020-01-01 17:01\" T &&\n+\t\tgit checkout -b side o &&\n+\t\ttest_commit --date \"2020-01-01 18:02\" B &&\n+\t\tgit checkout main &&\n+\t\tGIT_COMMITTER_DATE=\"2020-01-01 18:03\" git merge --no-ff -m x side &&\n+\t\tgit commit-graph write --reachable\n+\t)\n+'\n+\n+check_describe -C skew \"T-2-gHASH\" HEAD\n+\n test_expect_success 'setup misleading taggerdates' '\n \tGIT_COMMITTER_DATE=\"2006-12-12 12:31\" git tag -a -m \"another tag\" newer-tag-older-commit unique-file~1\n '\n-- \n2.56.0.237.g993442f913\n\n\n"},{"id":"557021","messageId":"20261031123149.yxap3%taahol@utu.fi","threadId":"66722","inReplyTo":"20261031065525.19883-2-torvalds@kernel.org","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Tuomas Ahola","fromEmail":"taahol@utu.fi","sentAt":"2026-10-31T12:31:49Z","receivedAt":"2026-10-31T12:31:49Z","isPatch":true,"sender":{"key":"taahol@utu.fi","avatar":"https://avatars.githubusercontent.com/u/114303477?v=4"},"body":"Linus Torvalds wrote:\n\n> From: Linus Torvalds \n> \n> The current merge window for Linux v7.4 showed annoying behavior with\n> 'git describe', where it doesn't actually follow the documented intent\n> of the result: the commit distance is miscomputed when the commit dates\n> aren't entirely reliable.\n> \n> This makes the 'git describe' output not match what the kernel\n> calculates in its localversion:\n> \n> \tlinux$ git describe && uname -r\n> \tv7.3-19342-g2a500a04d6f9\n> \t7.3.0-19059-g2a500a04d6f9\n> \n> and the kernel calculation is correct, and 'git describe' is wrong. The\n> number that 'git describe' gives (19342) is nonsense.\n> \n> The reason is that 'git describe' has walked the commit list past the\n> actual tagged release due to walking the commits purely in date order,\n> and is thus counting a few hundred commits that were already included in\n> Linux 7.3.\n> \n> The fix is to take the commit generation number into account when\n> ordering the commits. That will still fail if the repository has no\n> commit graph, but it at least improves on the situation in the common\n> case. With that one-liner fix, 'git describe' gets the correct commit\n> distance on my kernel tree:\n> \n> \tlinux$ git describe && uname -r\n> \tv7.3-19059-g2a500a04d6f9\n> \t7.3.0-19059-g2a500a04d6f9\n> \n> See also commit 1b600e659a (\"Compute accurate distances in git-describe\n> before output.\", 2007-01-27) which fixed a different issue in this same\n> area. Clearly the *intent* is that the distance number is actually the\n> real distance.\n> \n> Also add a test-case for this. Thanks to Claude.\n> \n> Signed-off-by: Linus Torvalds \n> ---\n> \n> [ Using my kernel.org email to send this, because setting that up is\n> easier than fighting gmail .. - Linus ]\n> \n> builtin/describe.c | 2 +-\n> t/t6120-describe.sh | 27 +++++++++++++++++++++++++++\n> 2 files changed, 28 insertions(+), 1 deletion(-)\n> \n> diff --git a/builtin/describe.c b/builtin/describe.c\n> index c0abc931a5..2cd597d919 100644\n> --- a/builtin/describe.c\n> +++ b/builtin/describe.c\n> @@ -328,7 +328,7 @@ static void append_suffix(int depth, const struct object_id *oid, struct strbuf\n> static void describe_commit(struct commit *cmit, struct strbuf *dst)\n> {\n> \tstruct commit *c, *gave_up_on = NULL;\n> -\tstruct prio_queue queue = { compare_commits_by_commit_date };\n> +\tstruct prio_queue queue = { compare_commits_by_gen_then_commit_date };\n> \tstruct commit_name *n;\n> \tstruct possible_tag all_matches[MAX_TAGS];\n> \tunsigned int match_cnt = 0, annotated_cnt = 0, cur_match;\n> diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh\n> index 7a7c46658a..a75f9227d9 100755\n> --- a/t/t6120-describe.sh\n> +++ b/t/t6120-describe.sh\n> @@ -749,6 +749,33 @@ test_expect_success 'setup: describe commits with disjoint bases 2' '\n> check_describe -C disjoint2 \"B-3-gHASH\" HEAD\n> check_describe -C disjoint2 --expect-failure \"B-3-gHASH\" --candidates=2 HEAD\n> \n> +# T\n> +# o----o----o----x\n> +# \\ /\n> +# `--o--'\n> +# B\n> +#\n> +# T is dated an hour before its parent, so a walk by commit date\n> +# reaches T's parent through B before it reaches T.\n> +#\n> +test_expect_success 'setup: describe a tag dated before its parent' '\n> +\tgit init skew &&\n> +\t(\n> +\t\tcd skew &&\n> +\t\tgit config core.commitGraph true &&\n> +\t\ttest_commit --date \"2020-01-01 18:00\" base &&\n> +\t\ttest_commit --date \"2020-01-01 18:01\" o &&\n> +\t\ttest_commit --annotate --date \"2020-01-01 17:01\" T &&\n> +\t\tgit checkout -b side o &&\n> +\t\ttest_commit --date \"2020-01-01 18:02\" B &&\n> +\t\tgit checkout main &&\n> +\t\tGIT_COMMITTER_DATE=\"2020-01-01 18:03\" git merge --no-ff -m x side &&\n> +\t\tgit commit-graph write --reachable\n> +\t)\n> +'\n\nJust a clueless rewrite of the above. I had quite fun writing it, so why not\nto share... it works and might even offer some not-completely-bogus food for\nthought.\n\n\tgit init skew &&\n\t(\n\t\tcd skew &&\n\t\ttest_config core.commitGraph true &&\n\t\ttest_commit base &&\n\t\ttest_commit o &&\n\t\ttest_tick=$(($test_tick - 3600)) &&\n\t\ttest_commit --annotate T &&\n\t\ttest_tick=$(($test_tick + 3600)) &&\n\t\tgit checkout o &&\n\t\ttest_commit B &&\n\t\tgit checkout main &&\n\t\ttest_merge x B &&\n\t\tgit commit-graph write --reachable\n\t)\n\n> +\n> +check_describe -C skew \"T-2-gHASH\" HEAD\n> +\n> test_expect_success 'setup misleading taggerdates' '\n> \tGIT_COMMITTER_DATE=\"2006-12-12 12:31\" git tag -a -m \"another tag\" newer-tag-older-commit unique-file~1\n> '\n> -- \n> 2.56.0.237.g993442f913\n> \n\n"},{"id":"557051","messageId":"xmqqa4nt2wch.fsf@gitster.g","threadId":"66722","inReplyTo":"20261031123149.yxap3%taahol@utu.fi","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-11-01T01:07:10Z","receivedAt":"2026-11-01T01:07:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tuomas Ahola writes:\n\n> Linus Torvalds wrote:\n>\n>> From: Linus Torvalds \n>> \n>> The current merge window for Linux v7.4 showed annoying behavior with\n>> 'git describe', where it doesn't actually follow the documented intent\n>> of the result: the commit distance is miscomputed when the commit dates\n>> aren't entirely reliable.\n>> \n>> This makes the 'git describe' output not match what the kernel\n>> calculates in its localversion:\n>> \n>> \tlinux$ git describe && uname -r\n>> \tv7.3-19342-g2a500a04d6f9\n>> \t7.3.0-19059-g2a500a04d6f9\n>> \n>> and the kernel calculation is correct, and 'git describe' is wrong. The\n>> number that 'git describe' gives (19342) is nonsense.\n>> \n>> The reason is that 'git describe' has walked the commit list past the\n>> actual tagged release due to walking the commits purely in date order,\n>> and is thus counting a few hundred commits that were already included in\n>> Linux 7.3.\n>> \n>> The fix is to take the commit generation number into account when\n>> ordering the commits. That will still fail if the repository has no\n>> commit graph, but it at least improves on the situation in the common\n>> case. With that one-liner fix, 'git describe' gets the correct commit\n>> distance on my kernel tree:\n>> \n>> \tlinux$ git describe && uname -r\n>> \tv7.3-19059-g2a500a04d6f9\n>> \t7.3.0-19059-g2a500a04d6f9\n>> \n>> See also commit 1b600e659a (\"Compute accurate distances in git-describe\n>> before output.\", 2007-01-27) which fixed a different issue in this same\n>> area. Clearly the *intent* is that the distance number is actually the\n>> real distance.\n>> \n>> Also add a test-case for this. Thanks to Claude.\n>> \n>> Signed-off-by: Linus Torvalds \n>> ---\n>> +test_expect_success 'setup: describe a tag dated before its parent' '\n>> +\tgit init skew &&\n>> +\t(\n>> +\t\tcd skew &&\n>> +\t\tgit config core.commitGraph true &&\n>> +\t\ttest_commit --date \"2020-01-01 18:00\" base &&\n>> +\t\ttest_commit --date \"2020-01-01 18:01\" o &&\n>> +\t\ttest_commit --annotate --date \"2020-01-01 17:01\" T &&\n>> +\t\tgit checkout -b side o &&\n>> +\t\ttest_commit --date \"2020-01-01 18:02\" B &&\n>> +\t\tgit checkout main &&\n>> +\t\tGIT_COMMITTER_DATE=\"2020-01-01 18:03\" git merge --no-ff -m x side &&\n>> +\t\tgit commit-graph write --reachable\n>> +\t)\n>> +'\n>\n> Just a clueless rewrite of the above. I had quite fun writing it, so why not\n> to share... it works and might even offer some not-completely-bogus food for\n> thought.\n>\n> \tgit init skew &&\n> \t(\n> \t\tcd skew &&\n> \t\ttest_config core.commitGraph true &&\n\nDoesn't this barf when it tries to register a clean-up action from\ninside a subshell?\n\n> \t\ttest_commit base &&\n> \t\ttest_commit o &&\n> \t\ttest_tick=$(($test_tick - 3600)) &&\n> \t\ttest_commit --annotate T &&\n> \t\ttest_tick=$(($test_tick + 3600)) &&\n> \t\tgit checkout o &&\n> \t\ttest_commit B &&\n\nQuite honestly, I do not see much value in this rewrite. Explicit\ndates and times from six years ago will eventually become distant\nhistory, but at least they made it clear, even in the source code,\nwhich event was recorded with what exact timestamp. In the\noriginal, it was much easier to tell which commit had a newer or\nolder timestamp than in the rewritten version. Can you tell if the\nannotated commit 'T' has a timestamp older by 3600, 3599, or 3601\nseconds than the next commit 'B', just by looking at the sequence\nabove and without inspecting how 'test_commit --annotate' is\nimplemented?\n\nUnless the focus of the test in question is \"I do not really care\nwhat time they record as long as they are reasonable and\nreproducible from one run to the next\", relying on $test_tick is\nprobably counterproductive. The test for this fix, where the issue\nis entirely about the relative ordering of timestamps on the\ninvolved commits, is a prime example of where using explicit --date\noptions would make things much easier to understand.\n\n> \t\tgit checkout main &&\n> \t\ttest_merge x B &&\n> \t\tgit commit-graph write --reachable\n> \t)\n>\n>> +\n>> +check_describe -C skew \"T-2-gHASH\" HEAD\n>> +\n>> test_expect_success 'setup misleading taggerdates' '\n>> \tGIT_COMMITTER_DATE=\"2006-12-12 12:31\" git tag -a -m \"another tag\" newer-tag-older-commit unique-file~1\n>> '\n>> -- \n>> 2.56.0.237.g993442f913\n>> \n\n"},{"id":"557074","messageId":"20261101094653.NKAEk%taahol@utu.fi","threadId":"66722","inReplyTo":"xmqqa4nt2wch.fsf@gitster.g","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Tuomas Ahola","fromEmail":"taahol@utu.fi","sentAt":"2026-11-01T09:46:53Z","receivedAt":"2026-11-01T09:46:53Z","isPatch":true,"sender":{"key":"taahol@utu.fi","avatar":"https://avatars.githubusercontent.com/u/114303477?v=4"},"body":"Junio C Hamano wrote:\n\n> Tuomas Ahola writes:\n> \n> > Linus Torvalds wrote:\n> >\n> >> ---\n> >> +test_expect_success 'setup: describe a tag dated before its parent' '\n> >> +\tgit init skew &&\n> >> +\t(\n> >> +\t\tcd skew &&\n> >> +\t\tgit config core.commitGraph true &&\n> >> +\t\ttest_commit --date \"2020-01-01 18:00\" base &&\n> >> +\t\ttest_commit --date \"2020-01-01 18:01\" o &&\n> >> +\t\ttest_commit --annotate --date \"2020-01-01 17:01\" T &&\n> >> +\t\tgit checkout -b side o &&\n> >> +\t\ttest_commit --date \"2020-01-01 18:02\" B &&\n> >> +\t\tgit checkout main &&\n> >> +\t\tGIT_COMMITTER_DATE=\"2020-01-01 18:03\" git merge --no-ff -m x side &&\n> >> +\t\tgit commit-graph write --reachable\n> >> +\t)\n> >> +'\n> >\n> > Just a clueless rewrite of the above. I had quite fun writing it, so why not\n> > to share... it works and might even offer some not-completely-bogus food for\n> > thought.\n> >\n> > \tgit init skew &&\n> > \t(\n> > \t\tcd skew &&\n> > \t\ttest_config core.commitGraph true &&\n> \n> Doesn't this barf when it tries to register a clean-up action from\n> inside a subshell?\n> \n\nHmm, only in Bash---something I forgot to test. This of course fails properly:\n\n\t$ make -C t/ SHELL=bash t6120-describe.sh \n\n> > \t\ttest_commit base &&\n> > \t\ttest_commit o &&\n> > \t\ttest_tick=$(($test_tick - 3600)) &&\n> > \t\ttest_commit --annotate T &&\n> > \t\ttest_tick=$(($test_tick + 3600)) &&\n> > \t\tgit checkout o &&\n> > \t\ttest_commit B &&\n> \n> Quite honestly, I do not see much value in this rewrite.\n\nWell, I did prepend the code with a \"caveat lector\", quite aware that the\nrewrite was somewhat pointless---if it had contained any good parts, that\nwould've been by sheer luck and happenstance.\n\nThat said, I actually tried my best, and I am quite happy that you gave that\nclueless waste of time a serious review. Thanks!\n\n> [...] Explicit\n> dates and times from six years ago will eventually become distant\n> history, but at least they made it clear, even in the source code,\n> which event was recorded with what exact timestamp. In the\n> original, it was much easier to tell which commit had a newer or\n> older timestamp than in the rewritten version. Can you tell if the\n> annotated commit 'T' has a timestamp older by 3600, 3599, or 3601\n> seconds than the next commit 'B', just by looking at the sequence\n> above and without inspecting how 'test_commit --annotate' is\n> implemented?\n> \n> Unless the focus of the test in question is \"I do not really care\n> what time they record as long as they are reasonable and\n> reproducible from one run to the next\", relying on $test_tick is\n> probably counterproductive. The test for this fix, where the issue\n> is entirely about the relative ordering of timestamps on the\n> involved commits, is a prime example of where using explicit --date\n> options would make things much easier to understand.\n> \n\nOkay, I'll be wiser next time.\n\n"},{"id":"557086","messageId":"xmqq5wyg1kus.fsf@gitster.g","threadId":"66722","inReplyTo":"20261101094653.NKAEk%taahol@utu.fi","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-11-01T18:12:59Z","receivedAt":"2026-11-01T18:12:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tuomas Ahola writes:\n\n> Hmm, only in Bash---something I forgot to test. This of course fails properly:\n>\n> \t$ make -C t/ SHELL=bash t6120-describe.sh \n\nIt is more like \"we must not use anything that relies on\ntest_when_finished in a subshell in any shell, and we wanted to\ndetect such mistaken use of test_config and its friends, but that\nunfortunately was something we couldn't do portably\". It would be\ngreat if you can make the check available to other shells ;-) but\nthat would be a completely separate topic.\n\nIn any case, let's pick up this patch and move it forward.\n\nThanks, all.\n\n"},{"id":"557116","messageId":"augrFe35Zci2mG+j@szeder.dev","threadId":"66722","inReplyTo":"xmqqa4nt2wch.fsf@gitster.g","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2026-11-02T06:17:57Z","receivedAt":"2026-11-02T06:17:57Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sat, Oct 31, 2026 at 06:07:10PM -0700, Junio C Hamano wrote:\n> Tuomas Ahola writes:\n> \n> > Linus Torvalds wrote:\n> >\n> >> +test_expect_success 'setup: describe a tag dated before its parent' '\n> >> +\tgit init skew &&\n> >> +\t(\n> >> +\t\tcd skew &&\n> >> +\t\tgit config core.commitGraph true &&\n> >> +\t\ttest_commit --date \"2020-01-01 18:00\" base &&\n> >> +\t\ttest_commit --date \"2020-01-01 18:01\" o &&\n> >> +\t\ttest_commit --annotate --date \"2020-01-01 17:01\" T &&\n> >> +\t\tgit checkout -b side o &&\n> >> +\t\ttest_commit --date \"2020-01-01 18:02\" B &&\n> >> +\t\tgit checkout main &&\n> >> +\t\tGIT_COMMITTER_DATE=\"2020-01-01 18:03\" git merge --no-ff -m x side &&\n> >> +\t\tgit commit-graph write --reachable\n> >> +\t)\n> >> +'\n> >\n> > Just a clueless rewrite of the above. I had quite fun writing it, so why not\n> > to share... it works and might even offer some not-completely-bogus food for\n> > thought.\n> >\n> > \tgit init skew &&\n> > \t(\n> > \t\tcd skew &&\n> > \t\ttest_config core.commitGraph true &&\n> \n> Doesn't this barf when it tries to register a clean-up action from\n> inside a subshell?\n\nIn both cases this is a freshly initialized repository, and the commit\ngraph has been enabled by default for a long time, so why do we need\nto set this config in the first place?\n\n\n"},{"id":"557173","messageId":"auiGP4XhObUzC9vD@pks.im","threadId":"66722","inReplyTo":"20261031065525.19883-2-torvalds@kernel.org","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-11-02T12:46:55Z","receivedAt":"2026-11-02T12:46:55Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Oct 30, 2026 at 11:55:03PM -0700, Linus Torvalds wrote:\n> From: Linus Torvalds \n> \n> The current merge window for Linux v7.4 showed annoying behavior with\n> 'git describe', where it doesn't actually follow the documented intent\n> of the result: the commit distance is miscomputed when the commit dates\n> aren't entirely reliable.\n> \n> This makes the 'git describe' output not match what the kernel\n> calculates in its localversion:\n> \n> \tlinux$ git describe && uname -r\n> \tv7.3-19342-g2a500a04d6f9\n> \t7.3.0-19059-g2a500a04d6f9\n> \n> and the kernel calculation is correct, and 'git describe' is wrong. The\n> number that 'git describe' gives (19342) is nonsense.\n\nOut of curiosity, how do you calculate the localversion...? *goes\nchecking* Ah, you seem to use `git rev-list --count --left-right $tag`,\nso you basically reimplement parts of git-describe(1).\n\nIs there a reason why you use your own script, e.g. because of a missing\nfeature? Besides the fact of course that git-describe(1) is buggy in\nthis particular case.\n\n> The fix is to take the commit generation number into account when\n> ordering the commits. That will still fail if the repository has no\n> commit graph, but it at least improves on the situation in the common\n> case. With that one-liner fix, 'git describe' gets the correct commit\n> distance on my kernel tree:\n> \n> \tlinux$ git describe && uname -r\n> \tv7.3-19059-g2a500a04d6f9\n> \t7.3.0-19059-g2a500a04d6f9\n> \n> See also commit 1b600e659a (\"Compute accurate distances in git-describe\n> before output.\", 2007-01-27) which fixed a different issue in this same\n> area. Clearly the *intent* is that the distance number is actually the\n> real distance.\n\nHmm. The big downside of this particular change is that you may now get\ndifferent results depending on whether or not you have a recent commit\ngraph. So you may get different results based on when git-maintenance(1)\nlast decided to update it, and that would in turn result in highly\npuzzling behaviour for the end user.\n\nSo...\n\n> diff --git a/builtin/describe.c b/builtin/describe.c\n> index c0abc931a5..2cd597d919 100644\n> --- a/builtin/describe.c\n> +++ b/builtin/describe.c\n> @@ -328,7 +328,7 @@ static void append_suffix(int depth, const struct object_id *oid, struct strbuf\n> static void describe_commit(struct commit *cmit, struct strbuf *dst)\n> {\n> \tstruct commit *c, *gave_up_on = NULL;\n> -\tstruct prio_queue queue = { compare_commits_by_commit_date };\n> +\tstruct prio_queue queue = { compare_commits_by_gen_then_commit_date };\n> \tstruct commit_name *n;\n> \tstruct possible_tag all_matches[MAX_TAGS];\n> \tunsigned int match_cnt = 0, annotated_cnt = 0, cur_match;\n\n... I wonder whether we should also call `ensure_generations_valid()`\nhere. That function is very expensive in cases where we don't have a\ncommit graph as it backfills generation numbers, and it may have to walk\nthe complete commit graph to do so. But isn't that better compared to\nsilently yielding a potentially-wrong result?\n\nThanks!\n\nPatrick\n\n"},{"id":"557181","messageId":"8fa4010d-d39f-4e78-ab01-be3e9d20a148@gmail.com","threadId":"66722","inReplyTo":"auiGP4XhObUzC9vD@pks.im","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-11-02T14:20:25Z","receivedAt":"2026-11-02T14:20:25Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 11/2/2026 7:46 AM, Patrick Steinhardt wrote:\n> On Fri, Oct 30, 2026 at 11:55:03PM -0700, Linus Torvalds wrote:\n>> From: Linus Torvalds \n\n>> diff --git a/builtin/describe.c b/builtin/describe.c\n>> index c0abc931a5..2cd597d919 100644\n>> --- a/builtin/describe.c\n>> +++ b/builtin/describe.c\n>> @@ -328,7 +328,7 @@ static void append_suffix(int depth, const struct object_id *oid, struct strbuf\n>> static void describe_commit(struct commit *cmit, struct strbuf *dst)\n>> {\n>> \tstruct commit *c, *gave_up_on = NULL;\n>> -\tstruct prio_queue queue = { compare_commits_by_commit_date };\n>> +\tstruct prio_queue queue = { compare_commits_by_gen_then_commit_date };\n>> \tstruct commit_name *n;\n>> \tstruct possible_tag all_matches[MAX_TAGS];\n>> \tunsigned int match_cnt = 0, annotated_cnt = 0, cur_match;\n> \n> ... I wonder whether we should also call `ensure_generations_valid()`\n> here. That function is very expensive in cases where we don't have a\n> commit graph as it backfills generation numbers, and it may have to walk\n> the complete commit graph to do so. But isn't that better compared to\n> silently yielding a potentially-wrong result?\nI came here to say exactly that. Even when a commit-graph exists, it can\nbe slightly behind the object database and so we need to fix up the\nnewest commits with generation number details.\n\nThe biggest downside is that it becomes very slow when a commit-graph\ndoesn't exist (it walks all reachable commits from the starting points)\nbut that's typically better than giving an incorrect answer.\n\nThanks,\n-Stolee\n\n"},{"id":"557208","messageId":"xmqqqzh3jhcy.fsf@gitster.g","threadId":"66722","inReplyTo":"8fa4010d-d39f-4e78-ab01-be3e9d20a148@gmail.com","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-11-02T17:03:25Z","receivedAt":"2026-11-02T17:03:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee writes:\n\n>>> +\tstruct prio_queue queue = { compare_commits_by_gen_then_commit_date };\n>>> \tstruct commit_name *n;\n>>> \tstruct possible_tag all_matches[MAX_TAGS];\n>>> \tunsigned int match_cnt = 0, annotated_cnt = 0, cur_match;\n>> \n>> ... I wonder whether we should also call `ensure_generations_valid()`\n>> here. That function is very expensive in cases where we don't have a\n>> commit graph as it backfills generation numbers, and it may have to walk\n>> the complete commit graph to do so. But isn't that better compared to\n>> silently yielding a potentially-wrong result?\n> I came here to say exactly that. Even when a commit-graph exists, it can\n> be slightly behind the object database and so we need to fix up the\n> newest commits with generation number details.\n>\n> The biggest downside is that it becomes very slow when a commit-graph\n> doesn't exist (it walks all reachable commits from the starting points)\n> but that's typically better than giving an incorrect answer.\n\nWhen we ended up spending the huge cost by doing this in a\nrepository without existing commit-graph or with an out of date\ncommit-graph, I wonder if it is possible to recoup the cost by\namortizing it over time by writing a commit-graph out?\n\n"},{"id":"557210","messageId":"fd7da4e6-ed30-4d83-8c8e-233a778f9a19@gmail.com","threadId":"66722","inReplyTo":"xmqqqzh3jhcy.fsf@gitster.g","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-11-02T17:52:23Z","receivedAt":"2026-11-02T17:52:23Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 11/2/2026 12:03 PM, Junio C Hamano wrote:\n> Derrick Stolee writes:\n> \n>>>> +\tstruct prio_queue queue = { compare_commits_by_gen_then_commit_date };\n>>>> \tstruct commit_name *n;\n>>>> \tstruct possible_tag all_matches[MAX_TAGS];\n>>>> \tunsigned int match_cnt = 0, annotated_cnt = 0, cur_match;\n>>>\n>>> ... I wonder whether we should also call `ensure_generations_valid()`\n>>> here. That function is very expensive in cases where we don't have a\n>>> commit graph as it backfills generation numbers, and it may have to walk\n>>> the complete commit graph to do so. But isn't that better compared to\n>>> silently yielding a potentially-wrong result?\n>> I came here to say exactly that. Even when a commit-graph exists, it can\n>> be slightly behind the object database and so we need to fix up the\n>> newest commits with generation number details.\n>>\n>> The biggest downside is that it becomes very slow when a commit-graph\n>> doesn't exist (it walks all reachable commits from the starting points)\n>> but that's typically better than giving an incorrect answer.\n> \n> When we ended up spending the huge cost by doing this in a\n> repository without existing commit-graph or with an out of date\n> commit-graph, I wonder if it is possible to recoup the cost by\n> amortizing it over time by writing a commit-graph out?\n\nI do like this idea, as we could take the structure that was\ncomputed and write it out with relatively small overhead at\nthat point. We are expecting the commit-graph to exist in\nmore places, and it has been baking for several years now.\nMaybe it's time to make that expectation more explicit and\nhave it become an opt-out instead of opt-in feature.\n\nIt does lead to some concerns that commands that are \"read\nonly\" become mutators of disk state. This is something that\ncould be rectified with appropriate guardrails.\n\nThanks,\n-Stolee\n\n\n"},{"id":"557221","messageId":"CAHk-=wijLfduoJyOM+AW6FS6c02cuEFRAuQWLE+uf7SGhj8jXA@mail.gmail.com","threadId":"66722","inReplyTo":"auiGP4XhObUzC9vD@pks.im","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2026-11-02T18:37:57Z","receivedAt":"2026-11-02T18:37:57Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, 2 Nov 2026 at 04:47, Patrick Steinhardt wrote:\n>\n> Out of curiosity, how do you calculate the localversion...? *goes\n> checking* Ah, you seem to use `git rev-list --count --left-right $tag`,\n> so you basically reimplement parts of git-describe(1).\n>\n> Is there a reason why you use your own script, e.g. because of a missing\n> feature? Besides the fact of course that git-describe(1) is buggy in\n> this particular case.\n\nI think it's partly historical, and partly because the kernel version\nhas actually always had the full \"three number\" version without the\n'v' (ie the kernel localversion uses \"7.3.0\" instead of \"v7.3\")\n\nThe kernel localversion is also configurable and wasn't tied to git\nspecifically, so it was never just \"git describe\". *I* want the git\nversion (and that's what \"CONFIG_LOCALVERSION_AUTO\" does for the\nkernel automatically if you are using a git tree), but I think all\ndistros do their own versioning manually).\n\nSo there's a whole 'setlocalversion' script in the kernel that does\nmany different cases, and it's all hacky and historical and I actually\nsuspect some of it predates \"git describe\" even existing.\n\n> Hmm. The big downside of this particular change is that you may now get\n> different results depending on whether or not you have a recent commit\n> graph. So you may get different results based on when git-maintenance(1)\n> last decided to update it, and that would in turn result in highly\n> puzzling behaviour for the end user.\n\nWell, honestly, no more puzzling than the odd existing behavior. But:\n\n> ... I wonder whether we should also call `ensure_generations_valid()`\n> here.\n\nI suspect that is just *way* too expensive in the bad case, but I\nwould hope/assume that any big repo already has generation numbers in\nit, so maybe it doesn't matter.\n\nMaybe add a \"--exact\" flag ot something to force it, and just document\nthat without it, you can get slightly odd numbers.\n\nBecasue rigth now, the numbers may be consistent, but when they can be\nconsistently *wrong*, I don't think that's a good thing either. It\ntook me a week of annoyance to even start looking at *why* they were\nwrong.\n\n Linus\n\n"},{"id":"557267","messageId":"aumKXUS7_x0i7ZU1@pks.im","threadId":"66722","inReplyTo":"CAHk-=wijLfduoJyOM+AW6FS6c02cuEFRAuQWLE+uf7SGhj8jXA@mail.gmail.com","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-11-03T07:16:45Z","receivedAt":"2026-11-03T07:16:45Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Nov 02, 2026 at 10:37:57AM -0800, Linus Torvalds wrote:\n> On Mon, 2 Nov 2026 at 04:47, Patrick Steinhardt wrote:\n> > Hmm. The big downside of this particular change is that you may now get\n> > different results depending on whether or not you have a recent commit\n> > graph. So you may get different results based on when git-maintenance(1)\n> > last decided to update it, and that would in turn result in highly\n> > puzzling behaviour for the end user.\n> \n> Well, honestly, no more puzzling than the odd existing behavior. But:\n> \n> > ... I wonder whether we should also call `ensure_generations_valid()`\n> > here.\n> \n> I suspect that is just *way* too expensive in the bad case, but I\n> would hope/assume that any big repo already has generation numbers in\n> it, so maybe it doesn't matter.\n\nWe nowadays generate commit graphs by default, yes. So usually\nrepositories should have one, but there will of course be outliers where\nthey don't exist because of whatever reason.\n\n> Maybe add a \"--exact\" flag ot something to force it, and just document\n> that without it, you can get slightly odd numbers.\n> \n> Becasue rigth now, the numbers may be consistent, but when they can be\n> consistently *wrong*, I don't think that's a good thing either. It\n> took me a week of annoyance to even start looking at *why* they were\n> wrong.\n\nI fully agree that being consistently wrong isn't great. I just wonder\nwhether being intermittently wrong is even worse because now the actual\nresult depends on timing. And consequently I'm a bit hesitant to\nintroduce an \"--exact\" flag and have people opt-in to a consistently\ncorrect result, because they won't even know that git-describe(1) may by\ndefault produce incorrect results.\n\nAn alternative that might be worth considering here is to instead make\nusers opt-out with \"--no-exact\", and then make that discoverable by\nemitting a warning in the case where we don't have a commit graph in the\nrepository.\n\nPatrick\n\n"},{"id":"557329","messageId":"CAHk-=wh6X3V49_RmYadHe-9+vEML1jDp2coy2YGBzrDqyDF1rg@mail.gmail.com","threadId":"66722","inReplyTo":"aumKXUS7_x0i7ZU1@pks.im","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2026-11-03T15:58:22Z","receivedAt":"2026-11-03T15:58:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, 2 Nov 2026 at 23:16, Patrick Steinhardt wrote:\n>\n> An alternative that might be worth considering here is to instead make\n> users opt-out with \"--no-exact\", and then make that discoverable by\n> emitting a warning in the case where we don't have a commit graph in the\n> repository.\n\nThat sounds sane - that way people who see performance issues but for\nsome reason or another don't want to do generation numbers in the repo\nitself (read-only legacy repositories?) have a way out.\n\n Linus\n\n"},{"id":"557393","messageId":"xmqq5wyd4epv.fsf@gitster.g","threadId":"66722","inReplyTo":"aumKXUS7_x0i7ZU1@pks.im","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-11-04T00:34:04Z","receivedAt":"2026-11-04T00:34:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n>> I suspect that is just *way* too expensive in the bad case, but I\n>> would hope/assume that any big repo already has generation numbers in\n>> it, so maybe it doesn't matter.\n>\n> We nowadays generate commit graphs by default, yes. So usually\n> repositories should have one, but there will of course be outliers where\n> they don't exist because of whatever reason.\n\nFWIW, one (out of two) tests that are expected to fail in\nt6120-describe.sh started failing in the feature-testbed CI job\nstarted failing. I think GIT_TEST_COMMIT_GRAPH is the culprit.\n\n> An alternative that might be worth considering here is to instead make\n> users opt-out with \"--no-exact\", and then make that discoverable by\n> emitting a warning in the case where we don't have a commit graph in the\n> repository.\n\nThat would work as an escape hatch. Sounds like a good plan.\n\n"},{"id":"557425","messageId":"CAL71e4PqEQkGoont3tL5wJWd1_itsaaxfX+DOkLj64x-S7xR1A@mail.gmail.com","threadId":"66722","inReplyTo":"xmqq5wyd4epv.fsf@gitster.g","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Kristofer Karlsson","fromEmail":"krka@spotify.com","sentAt":"2026-11-04T11:01:58Z","receivedAt":"2026-11-04T11:01:58Z","isPatch":true,"sender":{"key":"krka@spotify.com","avatar":"https://avatars.githubusercontent.com/u/5349266?v=4"},"body":"On Wed, 4 Nov 2026 at 01:34, Junio C Hamano wrote:\n>\n> Patrick Steinhardt writes:\n>\n> > An alternative that might be worth considering here is to instead make\n> > users opt-out with \"--no-exact\", and then make that discoverable by\n> > emitting a warning in the case where we don't have a commit graph in the\n> > repository.\n>\n> That would work as an escape hatch. Sounds like a good plan.\n>\n\nSorry for being a bit late to this thread; I have been playing\naround with a local prototype for this problem, and I wonder if it\nwould be possible to make the escape hatch largely unnecessary, by\nmaking the depth exact (or very close to it) without generation\nnumbers, at roughly today's cost.\n\nThe problem today is that the walk eagerly increments a tag's depth\nfor every commit it visits that does not carry the tag's bit yet,\nbut if the bit reaches that commit later via another path, the\ndepth is never decremented. My prototype instead keeps one counter\nof all visited commits, and per tag a counter of visited commits\nthat carry its bit. The depth is then the difference of the two,\nwhatever the order in which commits were visited. When an already\nvisited commit gains a bit late, that tag's counter is bumped and\nthe commit is enqueued again, so that the bit keeps propagating.\nAs bits are only ever added, that happens at most once per commit\nand tag.\n\nWhat remains is knowing when to stop. With the queue ordered by\ngeneration number, as in Linus's patch, that is exact for commits in\nthe commit-graph. For commits outside of it, it is exact as long as\nno commit is dated more than some epsilon before one of its own\nancestors. That is a sufficient condition, not a necessary one: on\nlinux.git the worst such case since v6.0 is about 60 days, but a\nmiscount also needs the skew to be right where the walk stops, and\nan epsilon of a week gave exact depths for every commit I tried,\nincluding the ones right around the skewed spots, at no measurable\ncost.\n\nA nice property is that this also works well with a partial\ncommit-graph. The commits outside of it are visited first, and only\nthose rely on the epsilon; once the walk reaches the commits in it,\nit can stop as soon as the depths are final. So the commit-graph\ndoes not need to be fully up to date to help, much like with other\nwalks that use generation numbers.\n\nFor 2a500a04d6f9 it gives v7.3-19059 with and without a\ncommit-graph, in about the same time as master, and it matches\n\"rev-list --count\" on the ~450 commits of the last merge window.\nBoth expected failures in t6120 pass with it, with and without\nGIT_TEST_COMMIT_GRAPH. The change is about 120 lines added and 60\nremoved in builtin/describe.c.\n\nWould this be worth pursuing, either instead of or on top of\nLinus's patch? If so, I would be happy to clean it up and send it.\n\nThanks,\nKristofer\n\n"},{"id":"557482","messageId":"xmqqv76c1mwb.fsf@gitster.g","threadId":"66722","inReplyTo":"CAL71e4PqEQkGoont3tL5wJWd1_itsaaxfX+DOkLj64x-S7xR1A@mail.gmail.com","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-11-04T18:17:56Z","receivedAt":"2026-11-04T18:17:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kristofer Karlsson writes:\n\n> What remains is knowing when to stop. With the queue ordered by\n> generation number, as in Linus's patch, that is exact for commits in\n> the commit-graph. For commits outside of it, it is exact as long as\n> no commit is dated more than some epsilon before one of its own\n> ancestors. That is a sufficient condition, not a necessary one: on\n> linux.git the worst such case since v6.0 is about 60 days, but a\n\nUnbelievably bad clock skew. I wonder if these people do not check\ntheir machine clock at all, but knowing the answer to that or learning\nwhy they don't would not help the issue at hand at all, so I'll stop.\n\n> miscount also needs the skew to be right where the walk stops, and\n> an epsilon of a week gave exact depths for every commit I tried,\n> including the ones right around the skewed spots, at no measurable\n> cost.\n>\n> A nice property is that this also works well with a partial\n> commit-graph. The commits outside of it are visited first, and only\n> those rely on the epsilon; once the walk reaches the commits in it,\n> it can stop as soon as the depths are final. So the commit-graph\n> does not need to be fully up to date to help, much like with other\n> walks that use generation numbers.\n>\n> For 2a500a04d6f9 it gives v7.3-19059 with and without a\n> commit-graph, in about the same time as master, and it matches\n> \"rev-list --count\" on the ~450 commits of the last merge window.\n> Both expected failures in t6120 pass with it, with and without\n> GIT_TEST_COMMIT_GRAPH. The change is about 120 lines added and 60\n> removed in builtin/describe.c.\n>\n> Would this be worth pursuing, either instead of or on top of\n> Linus's patch? If so, I would be happy to clean it up and send it.\n\nSounds interesting to me.\n\nThanks.\n\n"},{"id":"557486","messageId":"CAHk-=wj-5hp+FZBAqryzTwJ8DKvuNHub2e0kUG3g_+7borFfEQ@mail.gmail.com","threadId":"66722","inReplyTo":"xmqqv76c1mwb.fsf@gitster.g","subject":"Re: [PATCH] describe: count the distance correctly when commit dates are skewed","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2026-11-04T18:29:27Z","receivedAt":"2026-11-04T18:29:27Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, 4 Nov 2026 at 10:18, Junio C Hamano wrote:\n>\n> Unbelievably bad clock skew. I wonder if these people do not check\n> their machine clock at all, but knowing the answer to that or learning\n> why they don't would not help the issue at hand at all, so I'll stop.\n\nFor the kernel, people figured out what the issue is: it's not clock\nskew, it's intentional bad behavior by the gitlab Marge-bot merge\nlogic. Quoting Sasha Levin who root-caused it:\n\n The media dates seem to come from tooling too: The media CI merges MRs\n with Marge-bot, a GitLab merge bot, which rebases each one onto next\n using --keep-committers [1]. That copies the original committer date\n onto every rebased commit, so an MR landing after a newer one ends up\n older than its new parent.\n\n [1] https://gitlab.com/marge-org/marge-bot/-/commit/3fb8ab74b8781505530c21a28ac08080bc7deedb\n\nI have told people that I won't be pulling this kind of garbage in the\nfuture, but I don't know what insane workflows gitlab has forced on\npeople.\n\nThat flag is evil. It's intentionally lying about commit times. And\nit's what caused \"clock skew\" of up to three days in the kernel tree.\n\nPeople should not use gitlab and this disgusting flag.\n\nDon't ask me what complete insanity caused somebody to think that\nkeeping the committer name and email should mean that you should also\nlie about the commit *date*.\n\nWhat a complete shit-show.\n\n Linus\n\n"}]}