flakes: No longer compute revCount for local git repository by default

[Mic92]

Computing a revCount is expensive and might not work if the local history is not complete.
This particular fixes a long standing crash bug in Nix: #6073

Motivation

Depends on #13265

Context

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

revCount still throws an error as before.

[Mic92]

Flake regression is unrelated (500er http github error).

[edolstra]

This needs a release note since it's an incompatible change (and we probably shouldn't backport it for that reason).

BTW, maybe as an alternative we can make revCount computation lazy. I.e. it would only be computed if the flake actually uses the revCount attribute of the source tree.

[Mic92]

This needs a release note since it's an incompatible change (and we probably shouldn't backport it for that reason).

Yeah. I had the label still assigned before I made this change, when it was still a fix.

BTW, maybe as an alternative we can make revCount computation lazy. I.e. it would only be computed if the flake actually uses the revCount attribute of the source tree.

I considered the alternative but decided against it because it would still than try to compute the revCount when we override flake inputs in other flakes in which case revCount will always be recorded and checked in the flake.lock.

[DavHau]

If we'd just drop revCount, or make it opt-in, I wouldn't particularly mind it.

I fully agree. revCount should be remove from flakes and fetchTree.
(alternatively opt-in)

As expensive as computing revCount is, it doesn't justify the benefit. Its only use case seems to be generating a version string dynamically, but the shortRev can be used instead.

[grahamc]

Flake regression is unrelated (500er http github error).

On that note, FlakeHub prohibits a hard revcount dependency because it loses that data once it is published. In other words, it is unlikely a primarily-flakehub backed corpus would fail if the feature went away.

We did find a fair number of our own repository depended on the revcount to evaluate at first, which we ended up fixing. I'd encourage some sort of graceful upgrade path here, like continuing to calculate the revCount for the next N releases paired with a strong evaluation-time admonition about it going away.

[Mic92]

Flake regression is unrelated (500er http github error).

On that note, FlakeHub prohibits a hard revcount dependency because it loses that data once it is published. In other words, it is unlikely a primarily-flakehub backed corpus would fail if the feature went away.

We did find a fair number of our own repository depended on the revcount to evaluate at first, which we ended up fixing. I'd encourage some sort of graceful upgrade path here, like continuing to calculate the revCount for the next N releases paired with a strong evaluation-time admonition about it going away.

Ok. Than we need to make the revCount attribute lazy so we can issue a warning on first access.