summaryrefslogtreecommitdiff
path: root/git-request-pull.sh
diff options
context:
space:
mode:
authorLibravatar Michael Haggerty <mhagger@alum.mit.edu>2017-09-08 15:51:43 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-09-09 03:18:03 +0900
commit39c8df0cfe124565783bfc5eaaa3285c06b83fbf (patch)
tree1e72229d1ffc95266f8953f1d0622a97130b26e0 /git-request-pull.sh
parentThe fifth batch post 2.14 (diff)
downloadtgif-39c8df0cfe124565783bfc5eaaa3285c06b83fbf.tar.xz
packed-backend: don't adjust the reference count on lock/unlock
The old code incremented the packed ref cache reference count when acquiring the packed-refs lock, and decremented the count when releasing the lock. This is unnecessary because: * Another process cannot change the packed-refs file because it is locked. * When we ourselves change the packed-refs file, we do so by first modifying the packed ref-cache, and then writing the data from the ref-cache to disk. So the packed ref-cache remains fresh because any changes that we plan to make to the file are made in the cache first anyway. So there is no reason for the cache to become stale. Moreover, the extra reference count causes a problem if we intentionally clear the packed refs cache, as we sometimes need to do if we change the cache in anticipation of writing a change to disk, but then the write to disk fails. In that case, `packed_refs_unlock()` would have no easy way to find the cache whose reference count it needs to decrement. This whole issue will soon become moot due to upcoming changes that avoid changing the in-memory cache as part of updating the packed-refs on disk, but this change makes that transition easier. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-request-pull.sh')
0 files changed, 0 insertions, 0 deletions