Re: [PATCH v10 3/4] add `config_set` API for caching config-like files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think my proposal is a fix, and yours is a workaround. Semantically, calling setup_git_directory changes the config, so it should invalidate the cache. Your proposal consists in not filling-in the cache before it is invalidated, which works, but isn't very future-proof: if anybody fills-in the cache before the setup in the future, it will break it.

Now, both options can go together, then moving the check_pager_config call after setup_git_directory would avoid re-filling-in the cache. Intuitively, I'd say it's even needed in case git is started from a subdirectory and the .git/config contains pager-relevant stuff, but there might be complications.

----- Original Message -----
> 
> 
> On 7/18/2014 3:10 PM, Matthieu Moy wrote:
> > ----- Original Message -----
> >>  Documentation/technical/api-config.txt | 137 +++++++++++++++++
> >>  cache.h                                |  30 ++++
> >>  config.c                               | 263
> >>  +++++++++++++++++++++++++++++++++
> >>  3 files changed, 430 insertions(+)
> > 
> > I think the added call to git_config_clear() I proposed yesterday in
> > setup_git_directory_gently_1 should be part of this patch (with the
> > associated comment), just like this call:
> >
> 
> Oh, my bad, I thought you meant that I incorporate it with the
> git_config_raw() patch.
> I wanted to ask, can we call setup_git_directory_gently() earlier in
> execv_dashed_external()
> in git.c, which calls check_pager_config() for the first time which causes
> the
> incomplete cache to formed.
> If we can do it, we won't have to clear the cache every time
> setup_git_directory_gently_1()
> is called.
> 
> >> @@ -1707,6 +1967,9 @@ int git_config_set_multivar_in_file(const char
> >> *config_filename,
> >>  	lock = NULL;
> >>  	ret = 0;
> >>  
> >> +	/* Invalidate the config cache */
> >> +	git_config_clear();
> >> +
> >>  out_free:
> >>  	if (lock)
> >>  		rollback_lock_file(lock);
> > 
> > I have limited access to my email and no way to apply the patches today, so
> > I can't do a detailed review. But other than the remark above, I guess the
> > patch series is now all right and ready to cook in pu.
> > 
> 

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]