From: Michael Haggerty <redacted>
These patches are re-rolled onto the current master and incorporate
Junio's suggestion to rename "struct cached_refs" to "ref_cache".
This patch series provides an API for external code to invalidate the
ref cache that is used internally to refs.c. It also allows code
*within* refs.c to invalidate only the packed or only the loose refs
for a module/submodule.
IMPORTANT:
I won't myself have time to figure out who, outside of refs.c, has to
*call* invalidate_ref_cache(). The candidates that I know off the top
of my head are git-clone, git-submodule [1], and git-pack-refs. It
would be great if experts in those areas would insert calls to
invalidate_ref_cache() where needed.
Even better would be if the meddlesome code were changed to use the
refs API. I'd be happy to help expanding the refs API if needed to
accommodate your needs.
This is why the API for invalidating only packed or loose refs is
private. After code outside refs.c is changed to use the refs API, it
will get the optimal behavior for free (and at that time
invalidate_ref_cache() can be removed again).
[1] http://marc.info/?l=git&m=131827641227965&w=2
In this mailing list thread, Heiko Voigt stated that git-submodule
does not modify any references, so it should not have to use the
API.
Michael Haggerty (7):
invalidate_ref_cache(): rename function from invalidate_cached_refs()
invalidate_ref_cache(): take the submodule as parameter
invalidate_ref_cache(): expose this function in the refs API
clear_ref_cache(): rename parameter
clear_ref_cache(): extract two new functions
write_ref_sha1(): only invalidate the loose ref cache
clear_ref_cache(): inline function
refs.c | 59 +++++++++++++++++++++++++++++++----------------------------
refs.h | 8 ++++++++
2 files changed, 39 insertions(+), 28 deletions(-)
--
1.7.7.rc2
From: Michael Haggerty <redacted>
It is the cache that is being invalidated, not the references, and the
new name makes this unambiguous. Rename other items analogously:
* struct cached_refs -> struct ref_cache
* cached_refs (the variable) -> ref_cache
* clear_cached_refs() -> clear_ref_cache()
* create_cached_refs() -> create_ref_cache()
* get_cached_refs() -> get_ref_cache()
Signed-off-by: Michael Haggerty <redacted>
---
refs.c | 40 ++++++++++++++++++++--------------------
1 files changed, 20 insertions(+), 20 deletions(-)
@@ -134,15 +134,15 @@ static struct ref_entry *search_ref_array(struct ref_array *array, const char *n*Future:needtobein"struct repository"*whendoingafulllibification.*/-staticstructcached_refs{-structcached_refs*next;+staticstructref_cache{+structref_cache*next;chardid_loose;chardid_packed;structref_arrayloose;structref_arraypacked;/* The submodule name, or "" for the main repo. */charname[FLEX_ARRAY];-}*cached_refs;+}*ref_cache;staticstructref_entry*current_ref;
From: Michael Haggerty <redacted>
Make invalidate_ref_cache() an official part of the refs API. It is
currently a fact of life that code outside of refs.c mucks about with
references. This change gives such code a way of informing the refs
module that it should no longer trust its cache.
Signed-off-by: Michael Haggerty <redacted>
---
refs.c | 2 +-
refs.h | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
@@ -80,6 +80,14 @@ extern void unlock_ref(struct ref_lock *lock);/** Writes sha1 into the ref specified by the lock. **/externintwrite_ref_sha1(structref_lock*lock,constunsignedchar*sha1,constchar*msg);+/*+*Invalidatethereferencecacheforthespecifiedsubmodule.Use+*submodule=NULLtoinvalidatethecacheforthemainmodule.This+*functionmustbecalledifreferencesarechangedviaamechanism+*otherthantherefsAPI.+*/+externvoidinvalidate_ref_cache(constchar*submodule);+/** Setup reflog before using. **/intlog_ref_setup(constchar*ref_name,char*logfile,intbufsize);
From: Michael Haggerty <redacted>
Extract two new functions from clear_cached_refs():
clear_loose_ref_cache() and clear_packed_ref_cache().
Signed-off-by: Michael Haggerty <redacted>
---
refs.c | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
From: Michael Haggerty <redacted>
...for consistency with the rest of this module.
Signed-off-by: Michael Haggerty <redacted>
---
refs.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
From: Michael Haggerty <redacted>
Since write_ref_sha1() can only write loose refs and cannot write
symbolic refs, there is no need for it to invalidate the packed ref
cache.
Suggested by: Martin Fick [off-list ref]
Signed-off-by: Michael Haggerty <redacted>
---
refs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Michael Haggerty <redacted>
Instead of invalidating the ref cache on an all-or-nothing basis,
invalidate the cache for a specific submodule.
Signed-off-by: Michael Haggerty <redacted>
---
refs.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
From: Michael Haggerty <redacted>
clear_ref_cache() was only called from one place, so inline it
there.
Signed-off-by: Michael Haggerty <redacted>
---
refs.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
Hi,
On Mon, Oct 17, 2011 at 04:38:04AM +0200, mhagger@alum.mit.edu wrote:
I won't myself have time to figure out who, outside of refs.c, has to
*call* invalidate_ref_cache(). The candidates that I know off the top
of my head are git-clone, git-submodule [1], and git-pack-refs. It
would be great if experts in those areas would insert calls to
invalidate_ref_cache() where needed.
[...]
[1] http://marc.info/?l=git&m=131827641227965&w=2
In this mailing list thread, Heiko Voigt stated that git-submodule
does not modify any references, so it should not have to use the
API.
This is not entirely true. I was saying that my submodule-merge code is
currently the only one using the refs api for submodules and that does
not need to modify submodule refs. I imagine that there will be some
users when submodule support matures (e.g. recursive push).
Cheers Heiko
From: Michael Haggerty <hidden> Date: 2016-06-15 22:52:17
On 10/17/2011 08:47 PM, Heiko Voigt wrote:
On Mon, Oct 17, 2011 at 04:38:04AM +0200, mhagger@alum.mit.edu wrote:
quoted
[1] http://marc.info/?l=git&m=131827641227965&w=2
In this mailing list thread, Heiko Voigt stated that git-submodule
does not modify any references, so it should not have to use the
API.
This is not entirely true. I was saying that my submodule-merge code is
currently the only one using the refs api for submodules and that does
not need to modify submodule refs. I imagine that there will be some
users when submodule support matures (e.g. recursive push).
Sorry for misunderstanding/misrepresenting you; thanks for the
clarification.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/