Re: [PATCH 3/3] config: add core.sharedconfig
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Dec 10, 2010, 01:29 UTC
- Message-ID
- <AANLkTikAwvsb_rLc45ZTuTHEqYV78dAZCdgw-1f+D1+B@mail.gmail.com>
- In-Reply-To
- <7vwrnig6gr.fsf@alter.siamese.dyndns.org>
2010/12/10 Junio C Hamano <gitster@pobox.com>:
Show 13 quoted lines
>> @@ -910,6 +918,12 @@ int git_config(config_fn_t fn, void *data)
>>
>> repo_config = git_pathdup("config");
>> if (!access(repo_config, R_OK)) {
>> + git_config_from_file(get_shared_config, repo_config, NULL);
>> + if (core_shared_config) {
>> + ret += git_config_from_sha1(fn, core_shared_config, data);
>> + found += 1;
>> + }
>> +
>
> What is the point of this "found++" when you will increment it for finding
> the repository-local configuration anyway?It seems that every time a config source is used, found++. So I increase it because there's is another source used, a blob.
Show 32 quoted lines
> I originally liked what the first two tried to do, but think about the use > case. How would this whole thing work? > > - The user clones from the project to get a repository with a working > tree; > > - The user somehow learns that s/he can run one command to get > project-wide preference of the project: > > $ git config core.sharedconfig refs/remotes/origin/config:git.config > > - Everything hopefully should work the way project wishes in that blob, > unless the end user later overrides them by adding different settings > to .git/config. > > How is that different from: > > - The user clones from the project to get a repository with a working > tree; > > - The user somehow learns that s/he can run one command to get > project-wide preference of the project: > > $ ./setup-project-preference.sh > > Typically, such a ./setup-project-preference.sh script would only > consist of a series of "git config $foo $bar", so any user who can say > "git config core.sharedconfig $foo" should be able to use it as well. > > - Everything should work the way project wishes with the settings made to > .git/config by the script, unless the end user later overrides them by > modifying settings in .git/config.
The shared config can be updated automatically (after fetching, of course). Remote setup for a small team, for example, can benefit from this. Every time a new member joins, somebody adds new remote to the shared config and pushes out. Everybody else will have it.
> One minor difference is that some configuration variables are additive, > and you cannot subtract from them with your approach.
You can't subtract some keys from $HOME/.gitconfig by modifying $GIT_DIR/config either. I mean, that could be addressed in a general way, not specific to shared config.
-- Duy