Re: [PATCH 3/3] config: add core.sharedconfig

[Junio C Hamano <gitster@pobox.com>]

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> core.sharedconfig can take anything that resolves to a blob.
> $GIT_DIR/config will override the shared config. Nested shared
> config is not allowed.
>
> No protection is provided. It's up to the project to maintain good
> config. The config could be in a separate branch that only a few
> people are allowed to push, for example. To be safest, just put SHA-1
> there.
>
> git-fsck and git-prune should learn about this key and protect it from
> being pruned.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  Hopefully nobody sets core.sharedconfig = :path/to/config or similar
>
>  And I should not open $GIT_DIR/config twice. Well, it does not hurt
>  much.

That kind of sloppy thinking adds up, though.

> @@ -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?

>  		ret += git_config_from_file(fn, repo_config, data);
>  		found += 1;
>  	}

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.

One minor difference is that some configuration variables are additive,
and you cannot subtract from them with your approach.