Nguyán ThÃi Ngác Duy <pclouds@xxxxxxxxx> 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@xxxxxxxxx>
> ---
> 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.
--
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