From: Jonathan Nieder <jrnieder@gmail.com>
Date: Thu, 09 Dec 2010 18:19:24 GMT
Subject: Re: [PATCH 3/3] config: add core.sharedconfig
Message-ID: <20101209181924.GD5974@burratino>
In-Reply-To: <7vwrnig6gr.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> 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.

Wouldn't this ./setup-project-preference.sh have to set up a post-fetch hook
to update the configuration when the project's preferences change?