On Fri, 7 May 2010, Avery Pennarun wrote: > On Fri, May 7, 2010 at 3:31 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Fri, 7 May 2010, Linus Torvalds wrote: > >> Btw, another option might be to start searching ".gitconfig", but only > >> allow a certain "safe subset" of config options in that. Things that can > >> really be about the project itself, and not per-user or per-repository. > >> > >> And parse it before ~/.gitconfig and .git/config, so that people can > >> always override it. > >> > >> I dunno. Looking at the config options, there really aren't a lot of them > >> that make sense on a project scale. There's a few, though. Things like > >> > >> core.autocrlf > >> i18n.commitEnconfig > >> > >> and possibly others.. > > > > Given that only a subset of gitconfig could make sense to have > > distributed, I think the file should be named .gitparams to make the > > distinction clear. > > Since the options it *does* have are exactly the same as .git/config, > however, naming it .gitconfig makes sense. Well, I disagree. > I'd say just print a > warning when reading options that are going to be ignored for security > reasons (or because they're not known at all, or whatever). Or just make it .gitparams (or anything you wish) which is not the same as gitconfig. This way it is less likely to get bogus bug reports for options that aren't supported. Nicolas