On Thu, Nov 26, 2009 at 02:39:53PM +0100, Michael J Gruber wrote: > > Now, that is bike shedding ;) > > It seems to me that all ~/.*rc that I have are config files (.bashrc, > .xinitrc...), and all condif subdirs ~/.* are named by the > program/subsystem (.qt, .kde, .gnupg), which we cannot do any more, and > which is why I suggested .gitglobal. But I'd be fine with .gitrc. > > > On the other > > hand the --global option to git config specifies the .gitconfig in > > your HOME. > > That would have to change (ouch, ducking). Transition plan would be: > > ~/.gitconfig, ~/.gitrc/config:: > User-specific configuration file. Also called "global" > configuration file. Git looks in these locations in the > specified order and uses the first one it finds. > > $(prefix)/etc/gitconfig, $(prefix)/etc/gitrc/config:: > System-wide configuration file. Git looks in these locations > in the specified order and uses the first one it finds. > > This would mean no surprises for users with existing config, one could > teach the new preferred locations exclusively, and at some future point > one could phase out the old paths. > > Michael If we're going to bikeshed then let's throw a standard in there: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html ~/.gitrc/ doesn't make sense (it's not a file) and ~/.gitglobal/ hurts my eyes. "global"? Huh? Isn't it really user-specific? Why not call it ~/.gituser/ then? And what about the standard? The silly standard says to use ~/.config/git/. I'm quite happy with ~/.gitconfig and ~/.gitexclude if that's all there is to git's per-user configuration abilities, especially since ~/.gitexclude is less common. _Much_ less common from what I've seen in practice. Being that we cannot predict the future then there is some appeal to a top-leve ~/.config/git/-like directory. But... Like Junio said, I would stop only after adding support for the new paths. We don't want to confuse old or new users and we should never deprecate existing ~/.gitconfig. So now the "user" config is not just tied to one file but is instead multiple files? I dunno.. I kinda don't like that but the only reason is because I'm going to have to go and change code to take that into account. When I have to change code for little added benefit I ask questions. What about: $ git config --global foo.bar baz What file does that touch? ~/.gitconfig or ~/.config/git/config? What if ~/.gitconfig exists and ~/.config/git/config doesn't? What about vice versa? Okay, I also don't like it for that reason. What if you jump between git versions? Now the previous question is much more important -- it means that we *must* write to ~/.gitconfig to keep backwards compatibility otherwise someone will config something with git-vNew and be surprised when git-vOld does not find it. And if we must write to ~/.gitconfig then why does ~/.config/git/config even exist? I guess all I'm saying is that I'm quite happy with ~/.gitconfig and do not see a compelling reason as to why we'd need to transition to a different path. Yes, I'm being lazy. I don't feel like changing code when stuff works just fine right now ;-) And if we were to change it, then what about JGit, Dulwich, GitSharp, etc? Who's going to change those? To quote an old famous horse, "No sir, I don't like it." -- David -- 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