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

[Patrick Steinhardt <ps@pks.im>]

On Mon, Nov 02, 2026 at 10:37:57AM -0800, Linus Torvalds wrote:
> On Mon, 2 Nov 2026 at 04:47, Patrick Steinhardt <ps@pks.im> wrote:
> > 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.

We nowadays generate commit graphs by default, yes. So usually
repositories should have one, but there will of course be outliers where
they don't exist because of whatever reason.

> 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.

I fully agree that being consistently wrong isn't great. I just wonder
whether being intermittently wrong is even worse because now the actual
result depends on timing. And consequently I'm a bit hesitant to
introduce an "--exact" flag and have people opt-in to a consistently
correct result, because they won't even know that git-describe(1) may by
default produce incorrect results.

An alternative that might be worth considering here is to instead make
users opt-out with "--no-exact", and then make that discoverable by
emitting a warning in the case where we don't have a commit graph in the
repository.

Patrick