git-commit-vandalism/refs
Michael Haggerty 39c8df0cfe 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>
2017-09-09 03:18:03 +09:00
..
files-backend.c Merge branch 'mh/ref-lock-entry' 2017-08-26 22:55:09 -07:00
iterator.c prefix_ref_iterator: don't trim too much 2017-05-23 14:29:52 +09:00
packed-backend.c packed-backend: don't adjust the reference count on lock/unlock 2017-09-09 03:18:03 +09:00
packed-backend.h packed_refs_unlock(), packed_refs_is_locked(): new functions 2017-06-23 13:27:33 -07:00
ref-cache.c *.[ch] refactoring: make use of the FREE_AND_NULL() macro 2017-06-16 12:44:09 -07:00
ref-cache.h create_ref_entry(): remove check_name option 2017-05-23 14:29:56 +09:00
refs-internal.h Merge branch 'mh/ref-lock-entry' 2017-08-26 22:55:09 -07:00