git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 2/7] invalidate_ref_cache(): take the submodule as parameter

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Oct 12, 2011, 22:07 UTC
Message-ID
<4E960F91.5020103@alum.mit.edu>
In-Reply-To
<7vwrca81c7.fsf@alter.siamese.dyndns.org>
On 10/12/2011 09:19 PM, Junio C Hamano wrote:
Show 22 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> Instead of invalidating the ref cache on an all-or-nothing basis,
>> allow the cache for individual submodules to be invalidated.
> 
> That "allow" does not seem to describe what this patch does. It disallows
> the wholesale invalidation and forces the caller to invalidate ref cache
> individually.
> 
> Probably that is what all the existing callers want, but I would have
> expected that an existing feature would be kept, perhaps like this
> instead:
> 
> 	if (!submodule) {
> 		struct ref_cache *c;
>                 for (c = ref_cache; c; c = c->next)
>                 	clear_ref_cache(c);
> 	} else {
> 		clear_ref_cache(get_ref_cache(submodule);
> 	}
> 
> Not a major "vetoing" objection, just a comment.

Indeed, it is currently not possible for code outside of refs.c to implement "forget everything" using the "forget one" function (because there is no API for getting the list of caches that are currently in memory).

A "forget everything" function might be useful for code that delegates to a subprocess, if it does not know what submodules the subprocess has tinkered with. Heiko, does that apply to the future submodule code?

Your specific suggestion would not work because currently submodule==NULL signifies the main module. However, it would be easy to add the few-line function when/if it is needed.

I guess the bigger issue for me is whether the whole submodule cache thing is going to continue to be needed. I really am too ignorant of how submodules work to be able to judge. From Heiko's recent email it sounds like things might be moving in the direction of "top-level git doesn't need to know much about submodules because it delegates to subprocesses". He also said that submodule references are not modified by the top-level git process, meaning that it might be sensible for the submodule reference cache to be less capable than the main module reference cache.

But if things move in the other direction (submodules handled by the top-level git process), let alone if git is libified, then it seems inevitable that there will someday be a "submodule" object that keeps track of its own ref cache, with the submodule objects rather than the submodule reference caches looked up by submodule name.

Given that I'm still very new to the codebase, I'm mostly making "peephole changes" and so I'm happy to get your feedback about how this fits into the grand scheme of things.

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Junio C HamanoNext: Junio C Hamano
Message 41 of 54 in “Retain caches of submodule refs”
  1. 0/6 Retain caches of submodule refsMichael Haggerty, Aug 12, 2011
  2. 1/6 Extract a function clear_cached_refs()Michael Haggerty, Aug 12, 2011
  3. 2/6 Access reference caches only through new function get_cached_refs().Michael Haggerty, Aug 12, 2011
  4. Junio C HamanoAug 14, 2011
  5. Michael HaggertyAug 23, 2011
  6. 3/6 Change the signature of read_packed_refs()Michael Haggerty, Aug 12, 2011
  7. 4/6 Allocate cached_refs objects dynamicallyMichael Haggerty, Aug 12, 2011
  8. Junio C HamanoAug 14, 2011
  9. 5/6 Store the submodule name in struct cached_refs.Michael Haggerty, Aug 12, 2011
  10. 6/6 Retain caches of submodule refsMichael Haggerty, Aug 12, 2011
  11. Heiko VoigtAug 13, 2011
  12. Michael HaggertyAug 24, 2011
  13. Heiko VoigtAug 24, 2011
  14. Junio C HamanoAug 16, 2011
  15. Michael HaggertyAug 24, 2011
  16. Michael HaggertyOct 9, 2011
  17. Junio C HamanoOct 9, 2011
  18. 0/2 Provide API to invalidate refs cacheMichael Haggerty, Oct 10, 2011
  19. 1/2 invalidate_cached_refs(): take the submodule as parameterMichael Haggerty, Oct 10, 2011
  20. 2/2 invalidate_cached_refs(): expose this function in refs APIMichael Haggerty, Oct 10, 2011
  21. 0/7 Provide API to invalidate refs cacheMichael Haggerty, Oct 10, 2011
  22. 1/7 invalidate_ref_cache(): rename function from invalidate_cached_refs()Michael Haggerty, Oct 10, 2011
  23. Junio C HamanoOct 11, 2011
  24. Michael HaggertyOct 11, 2011
  25. 2/7 invalidate_ref_cache(): take the submodule as parameterMichael Haggerty, Oct 10, 2011
  26. 3/7 invalidate_ref_cache(): expose this function in refs APIMichael Haggerty, Oct 10, 2011
  27. 4/7 clear_cached_refs(): rename parameterMichael Haggerty, Oct 10, 2011
  28. 5/7 clear_cached_refs(): extract two new functionsMichael Haggerty, Oct 10, 2011
  29. 6/7 write_ref_sha1(): only invalidate the loose ref cacheMichael Haggerty, Oct 10, 2011
  30. 7/7 clear_cached_refs(): inline functionMichael Haggerty, Oct 10, 2011
  31. Junio C HamanoOct 11, 2011
  32. Michael HaggertyOct 11, 2011
  33. Julian PhillipsOct 11, 2011
  34. Junio C HamanoOct 11, 2011
  35. 0/7 Provide API to invalidate refs cacheMichael Haggerty, Oct 12, 2011
  36. 1/7 invalidate_ref_cache(): rename function from invalidate_cached_refs()Michael Haggerty, Oct 12, 2011
  37. Junio C HamanoOct 12, 2011
  38. Michael HaggertyOct 12, 2011
  39. 2/7 invalidate_ref_cache(): take the submodule as parameterMichael Haggerty, Oct 12, 2011
  40. Junio C HamanoOct 12, 2011
  41. Michael HaggertyOct 12, 2011
  42. Junio C HamanoOct 17, 2011
  43. Michael HaggertyNov 3, 2011
  44. Junio C HamanoNov 3, 2011
  45. 3/7 invalidate_ref_cache(): expose this function in refs APIMichael Haggerty, Oct 12, 2011
  46. 4/7 clear_cached_refs(): rename parameterMichael Haggerty, Oct 12, 2011
  47. 5/7 clear_cached_refs(): extract two new functionsMichael Haggerty, Oct 12, 2011
  48. 6/7 write_ref_sha1(): only invalidate the loose ref cacheMichael Haggerty, Oct 12, 2011
  49. 7/7 clear_cached_refs(): inline functionMichael Haggerty, Oct 12, 2011
  50. Junio C HamanoOct 12, 2011
  51. Heiko VoigtOct 10, 2011
  52. Michael HaggertyOct 11, 2011
  53. Heiko VoigtOct 11, 2011
  54. Heiko VoigtAug 13, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.