commit d0a5242062823dc8297b80e1876c1eb6a00fd164
author Martin Fick <mfick@nvidia.com> Thu Nov 06 07:20:13 2025 -0800
committer mfick <mfick@nvidia.com> Fri Nov 21 18:42:07 2025 +0000
tree ac5eb7d41f0c791679c3a374bc5bc25ff8d868cf
parent 8b23132d5874e1d4245e9cab4c279395f56328c3

Do not always refresh packed-refs during ref updates

Replace the refreshPackedRefs() method with a new getLockedPackedRefs()
method taking a LockFile as a parameter to better clarify the real
intention of this method and to better differentiate when it should be
called versus getPackedRefs(). This differentiation is important because
SnapshottingRefDirectory overrides getPackedRefs() to cache refs
throughout a whole request without ever verifying if they have changed
during normal read paths. However, during ref update paths,
SnapshottingRefDirectory needs to still verify if the packed-refs have
changed, and having two methods ensures that for a
SnapshottingRefDirectory the two methods will be different. The LockFile
argument is not really required to create a correct
getLockedPackedRefs(), but it does help ensure the method is only used
in ref update paths.

Unlike the replaced refreshPackedRefs() method, but similar to the
getPackedRefs() method, the new getLockedPackedRefs() method also
benefits from caching if the packed-refs file has not changed making
ref updates much faster! This takes a push down from almost 30s to
around 13s, on NFS using after_open semantics and a repository with 4M+
refs. With the same setup, this change also improves ten parallel
pushes from 60s/push to around 40s/push (so both latency and throughput
are improved). This does add some extra risk in that the jgit "trust"
settings are now also applied during ref update paths where as
previously a re-read was always done in these paths. Depending on your
point of view, this change can also be seen as a bug fix, not just a
performance improvement.

Change-Id: I8e9636c37802a249c9f5555748d69045beeea608
Signed-off-by: Martin Fick <mfick@nvidia.com>