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

[David Aguilar <davvid@gmail.com>]

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