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

Re: [PATCH 6/6] Retain caches of submodule refs

From: Michael Haggerty <hidden>
Date: 2016-06-15 22:52:13

On 08/17/2011 12:45 AM, Junio C Hamano wrote:
All the changes except for this one made sense to me, but I am not sure
about this one. How often do we look into different submodule refs in the
same process over and over again?
I am having pangs of uncertainty about this patch.

Previous to this patch, the submodule reference cache was only used for
the duration of one call to do_for_each_ref().  (It was not *discarded*
until later, but the old cache was never reused.)  Therefore, the
submodule reference cache was implicitly invalidated between successive
uses.

After this change, submodule ref caches are invalidated whenever
invalidate_cached_refs() is called.  But this function is static, and it
is only called when main-module refs are changed.

AFAIK there is no way within refs.c to add, modify, or delete a
submodule reference.  But if other code modifies submodule references
directly, then the submodule ref cache in refs.c would become stale.
Moreover, there is currently no API for invalidating the cache.

So I think I need help from a submodule guru (Heiko?) who can tell me
what is done with submodule references and whether they might be
modified while a git process is executing in the main module.  If so,
then either this patch has to be withdrawn, or more work has to be put
in to make such code invalidate the submodule reference cache.

Sorry for the oversight, but I forgot that not all code necessarily uses
the refs.c API when dealing with references (a regrettable situation, BTW).

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help