`nix-build` fails in shallow clones on Nix 2.35 due to forcing `revCount`

[bryango]

With Nix 2.35.1, plain nix-build fails in shallow clones with the default flake-compat setup:

… while evaluating the attribute 'revCount'

… while calling the '__forceLazyFetcherAttr' builtin

error: '<REPO>' is a shallow Git repository, so 'revCount' is not available

Selecting the package explicitly by nix-build -A default does succeed.

Cause

• Lazy revCount nix#15772 made revCount lazy. For a shallow repository, fetching the source succeeds, but explicitly forcing revCount now correctly fails because the full count is unavailable.

• flake-compat merges sourceInfo into result, then exposes almost the whole result through defaultNix:

  defaultNix =
    builtins.removeAttrs result [ "__functor" ]
    // ...

  This places the lazy revCount at the top level of defaultNix. The plain nix-build examines every top-level attribute and forces each value to determine whether it is a derivation.

Consequently, bare nix-build forces revCount even when neither the selected package nor the flake outputs use it.

A real-world instance occurred in nix-community/hydra-check#105, after CI began receiving Nix 2.35.1: https://github.com/nix-community/hydra-check/actions/runs/29458017080.

Possible fix / workarounds

One option is to stop exposing the redundant top-level revCount alias through the legacy build projection:

defaultNix =
  builtins.removeAttrs result [ "__functor" "revCount" ]
  // ...

This would still preserve revCount through:

• self.revCount during flake output evaluation;
• (import flake-compat ...).outputs.revCount;
• defaultNix.sourceInfo.revCount.

On a full repository those paths would continue to return the correct count. Downstream projects can currently either:

• use nix-build -A default, avoiding the top-level scan (which we did); or
• fetch the complete Git history so revCount can be computed.