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