Lazy revCount

[roberth]

Motivation

1. Few exprs need revCount, so let's only fetch it when needed.
   (or when serializing the lock)
2. Current Nix has a bug where nix build git+file:///path/to/repo would go getAccessorFromWorkdir and fail to throw the revcount error, returning a number that's too low instead. I'm unsure whether the CLI should infer shallow = true;, but I'm open to the idea if users need it. For now I've kept it simple and "pure" for what that's worth.

Context

Written partially at OceanSprint 2026

---

Add 👍 to pull requests you find important.

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

[edolstra]

I once implemented lazy attrs/revcounts (https://github.com/edolstra/nix/compare/98624325311300b1373c61df565fd49f4325b55c..a68da5fc4b8fe7ae6b406385a26f2b83c7550d10), but it turned out to be useless, because fingerprint computation (needed for the eval cache) requires the revcount strictly. So we don't actually gain anything from the laziness.

[xokdvium]

@edolstra, there's the roberth@6491749 commit in this branch though. It does kinda make sense to me.

[roberth]

I have confirmed it to work by temporarily putting an exception right at the start of getRevCount and running nix build nixpkgs#hello with that build.

[xokdvium]

Hm is nixpkgs in your case a git+ input? I think we still have the eager revCount there because we serialise the whole lock file string instead of making an attribute set with thunks that would get passed to call-flake.nix

[xokdvium]

Some nitpicks

[xokdvium]

Hm does the lock file not get serialised in this case? I'm a bit confused why revCount would not be computed in this case...

[roberth]

The short of it is that the root node does not get locked the way inputs do.

When used as a proper input, it gets locked and serialized to JSON before being taken apart again by call-flake.nix.
So that kills the laziness for inputs.
Whether that's a good thing or not is debatable. It can be argued both ways:

• Storing is scalable: computing it and storing it in the lock means we could trust the value in dependency lock files (like Reuse input lock files #7730 presumably would), limiting the number of revCount computations to direct dependencies instead of a significant portion of the whole inputs closure.
• Computing it lazily is perfect as long as revCount is not accessed. Nixpkgs doesn't use it.

Wildcard solution: model it as a build trace so that it can be substituted. (benevolent IFD)

EDIT: IMO the real solution is for fetchTree to take a page from GraphQL and require all output attributes to be explicitly requested. This idea would then extend to certain attributes when it comes to flake inputs. In other words, revCount would be opt-in.

[edolstra]

Since revCount is functionally determined by rev (already part
of the fingerprint), we only need to include its presence in
the fingerprint, not its value.

Unfortunately this is not the case, since users can specify arbitrary values for revCount (e.g. in flake.lock) , and thereby poison the eval cache.

[roberth]

Unfortunately this is not the case, since users can specify arbitrary values for revCount (e.g. in flake.lock) , and thereby poison the eval cache.

Fixed in 220ccc7

[xokdvium]

Makes sense to me. Maybe it's slightly hacky, but seems worth it. The general mechanism of transforming a fun into a thunk could be factored out in the future however. Not worth the trouble for now though.

[SuperSandro2000]

I think this PR broke "nix flake update --commit-lock-file" for git+https inputs as the comparison in lockfile.cc was tripped by the lazy revCount being evaluated on one side and not on the other side.

Which means I got lots of updates like this:

    • Updated input 'yammat':
        'git+https://gitea.c3d2.de/c3d2/yammat.git?ref=refs/heads/master&rev=22afd7abf966e8e34f9f1d94162bfb0c7d3b6d6b' (2026-05-03)
      → 'git+https://gitea.c3d2.de/c3d2/yammat.git?ref=refs/heads/master&rev=22afd7abf966e8e34f9f1d94162bfb0c7d3b6d6b' (2026-05-03)

Since my C++ knowledge is none existent I asked an LLM to try to figure something out and in the end this came out:

diff --git a/src/libflake/lockfile.cc b/src/libflake/lockfile.cc
index 75127521b..ffd4ec8f5 100644
--- a/src/libflake/lockfile.cc
+++ b/src/libflake/lockfile.cc
@@ -364,11 +364,23 @@ std::ostream & operator<<(std::ostream & stream, const Node::Edge & edge)
     return stream;
 }

+/* Locked refs can differ only in `revCount`, which is a lazy computation
+   in a freshly resolved git input but a concrete integer in a lock file.
+   revCount is derived from `rev`, so ignore it when comparing. */
+static bool lockedRefsEqual(const FlakeRef & a, const FlakeRef & b)
+{
+    auto ia = a.input.attrs;
+    auto ib = b.input.attrs;
+    ia.erase("revCount");
+    ib.erase("revCount");
+    return a.subdir == b.subdir && ia == ib;
+}
+
 static bool equals(const Node::Edge & e1, const Node::Edge & e2)
 {
     if (auto n1 = std::get_if<0>(&e1))
         if (auto n2 = std::get_if<0>(&e2))
-            return (*n1)->lockedRef == (*n2)->lockedRef;
+            return lockedRefsEqual((*n1)->lockedRef, (*n2)->lockedRef);
     if (auto f1 = std::get_if<1>(&e1))
         if (auto f2 = std::get_if<1>(&e2))
             return *f1 == *f2;

No idea if this breaks caching in some other place or majorly breaks something, so please take it with a grain of salt, but it fixes my imminent issue and now nix flake update --commit-lock-file no longer adds many extra entries that should be equal.

I think it should be safe to compare as git commits cannot be freely reordered without changing the hash, so revCount cannot change without the commit changing.

[xokdvium]

Hm, comparison should probably force those attributes as needed. I assumed that would be the case, but apparently not. Do you have a reproducer?

[SuperSandro2000]

It's pretty easy to reproduce:
Have one flake input that has an update and another one that uses git+http and then you always get a ghost update for the second.

Basically run nix flake update --commit-lock-file in this repo https://gitea.c3d2.de/c3d2/nix-config

[SuperSandro2000]

This is an example commit https://gitea.c3d2.de/c3d2/nix-config/commit/014474926831036656ac5a323884cf34524d281a with the broken behaviour.

[xokdvium]

Tentatively put up #16430 with the fix. Really silly bug