Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.

From: David Aguilar <davvid@gmail.com>
Date: Nov 26, 2009, 20:07 UTC
Message-ID: <20091126200728.GA2665@gmail.com>
In-Reply-To: <4B0E8529.3040609@drmicha.warpmail.net>

On Thu, Nov 26, 2009 at 02:39:53PM +0100, Michael J Gruber wrote:

Show 28 quoted lines

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