Re: [PATCH 3/3] config: add core.sharedconfig
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Dec 9, 2010, 18:19 UTC
- Message-ID
- <20101209181924.GD5974@burratino>
- In-Reply-To
- <7vwrnig6gr.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 28 quoted lines
> 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?