From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Fri, 10 Dec 2010 01:29:55 GMT
Subject: Re: [PATCH 3/3] config: add core.sharedconfig
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>:
>> @@ -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.

> 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