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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html