Re: [PATCH] describe: count the distance correctly when commit dates are skewed

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 2, 2026, 18:37 UTC
Message-ID: <CAHk-=wijLfduoJyOM+AW6FS6c02cuEFRAuQWLE+uf7SGhj8jXA@mail.gmail.com>
In-Reply-To: <auiGP4XhObUzC9vD@pks.im>

On Mon, 2 Nov 2026 at 04:47, Patrick Steinhardt <ps@pks.im> wrote:

Show 8 quoted lines

>
> Out of curiosity, how do you calculate the localversion...? *goes
> checking* Ah, you seem to use `git rev-list --count --left-right $tag`,
> so you basically reimplement parts of git-describe(1).
>
> Is there a reason why you use your own script, e.g. because of a missing
> feature? Besides the fact of course that git-describe(1) is buggy in
> this particular case.

I think it's partly historical, and partly because the kernel version has actually always had the full "three number" version without the 'v' (ie the kernel localversion uses "7.3.0" instead of "v7.3")

The kernel localversion is also configurable and wasn't tied to git specifically, so it was never just "git describe". *I* want the git version (and that's what "CONFIG_LOCALVERSION_AUTO" does for the kernel automatically if you are using a git tree), but I think all distros do their own versioning manually).

So there's a whole 'setlocalversion' script in the kernel that does many different cases, and it's all hacky and historical and I actually suspect some of it predates "git describe" even existing.

Show 5 quoted lines

> Hmm. The big downside of this particular change is that you may now get
> different results depending on whether or not you have a recent commit
> graph. So you may get different results based on when git-maintenance(1)
> last decided to update it, and that would in turn result in highly
> puzzling behaviour for the end user.

Well, honestly, no more puzzling than the odd existing behavior. But:

> ... I wonder whether we should also call `ensure_generations_valid()`
> here.

I suspect that is just *way* too expensive in the bad case, but I would hope/assume that any big repo already has generation numbers in it, so maybe it doesn't matter.

Maybe add a "--exact" flag ot something to force it, and just document that without it, you can get slightly odd numbers.

Becasue rigth now, the numbers may be consistent, but when they can be consistently *wrong*, I don't think that's a good thing either. It took me a week of annoyance to even start looking at *why* they were wrong.

            Linus