2010/12/10 Junio C Hamano <gitster@xxxxxxxxx>:
>> @@ -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
--
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