Thread (22 messages) flat view 22 messages, 3 authors, 2016-06-15

Re: [PATCH 12/12] refs: do not invalidate the packed-refs cache unnecessarily

From: Jeff King <hidden>
Date: 2016-06-15 22:57:42

On Tue, Jun 11, 2013 at 11:48:32PM +0200, Michael Haggerty wrote:
Now that we keep track of the packed-refs file metadata, we can detect
when the packed-refs file has been modified since we last read it, and
we do so automatically every time that get_packed_ref_cache() is
called.  So there is no need to invalidate the cache automatically
when lock_packed_refs() is called; usually the old copy will still be
valid.

Signed-off-by: Michael Haggerty <redacted>
---
This patch is optional.  It makes the assumption that the metadata
stored in stat_validity are adequate to reliably detect when the
packed-refs file has changed.  Given that we are about to rewrite the
file, it is perhaps even more crucial not to make a mistake in this
codepath than in others.  So if the stat_validity check is not
considered safe enough, it might be prudent to omit this patch and
continue to reload the packed-refs data here unconditionally.
I doubt that the risk is very high, but I'd also doubt that this
provides any useful performance improvement, because it is mostly
happening during a `git pack-refs` call. The exception is packing for a
ref deletion, and it could potentially speed up a receive-pack that was
deleting many refs.

I don't have a strong opinion either way.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help