Open marienz opened 5 months ago
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2024-05-29-nix-team-meeting-minutes-148/46195/1
Same here. Can confirm that this behavior is observed on 2.23, but not on 2.18.
Repeatedly fetching the same fixed
rev
usingfetchGit
hits the network each time once the cache is older thantarball-ttl
(not just once to refresh the cache).Steps To Reproduce
This hits the network, seemingly to resolve the HEAD ref: the network hit occcurs between
(I'm noticing this hits the network because it takes about 800ms instead of about 10ms, but I'm in Australia: if you're closer to Github the problem may be less noticeable.)
Expected behavior
If the requested rev is already cached, the cache is used without hitting the network. Or if it is necessary to verify the requested rev is obtainable from a particular ref (to avoid #7120): this verification only occurs once every
tarball-ttl
, not on every attempt once the cache is older thantarball-ttl
.nix-env --version
output nix-env (Nix) 2.22.1Additional context
Nix 2.18.2 does not have this problem.
It looks like the network hit occurs from the
getDefaultRef()
call in git.cc: passing in someref
makes me hit the cache again. (Any value forref
seems to work, although I'm guessing that's only because of #7120.) From there we end up inreadHeadCached()
which hits the network if the cachedHEAD
file is older thantarball-ttl
, seemingly without updating that file.6830 is somewhat related: that issue points out that caching revs is undesirable if Nix is fetching by ref (without a rev specified). If a rev is specified, caching seems very desirable.
Priorities
Add :+1: to issues you find important.