[PATCH] let core.excludesfile default to ~/.gitignore.

[PATCH] let core.excludesfile default to ~/.gitignore.

[Matthieu Moy]

It seems this is the value most users set, so let's make it the default.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
A funny experiment:

http://www.google.com/search?q=core.excludesfile+-%22~/.gitignore%22
Results 1 - 10 of about 3,890 for core.excludesfile -"~/.gitignore"

http://www.google.com/search?q=core.excludesfile+%22~/.gitignore%22
Results 1 - 10 of about 7,990 for core.excludesfile "~/.gitignore"

So, most of the time someone mentions core.excludesfile on the web,
~/.gitignore is mentionned right after.


I'd have expected a place near config.c to set the default value for
any config variable, but I can't find such thing, so I guess the
caller is the one that should set the default, which is what I do in
the patch.

 Documentation/config.txt |    1 +
 dir.c                    |    9 ++++++++-
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 39d1226..0c55e52 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -384,6 +384,7 @@ core.excludesfile::
 	of files which are not meant to be tracked.  "~/" is expanded
 	to the value of `$HOME` and "~user/" to the specified user's
 	home directory.  See linkgit:gitignore[5].
+	Default: ~/.gitignore.
 
 core.editor::
 	Commands such as `commit` and `tag` that lets you edit
diff --git a/dir.c b/dir.c
index d0999ba..dcea6ad 100644
--- a/dir.c
+++ b/dir.c
@@ -914,9 +914,16 @@ void setup_standard_excludes(struct dir_struct *dir)
 
 	dir->exclude_per_dir = ".gitignore";
 	path = git_path("info/exclude");
+	if (!excludes_file) {
+		const char *home = getenv("HOME");
+		char *user_gitignore = malloc(strlen(home) + strlen("/.gitignore") + 1);
+		strcpy(user_gitignore, home);
+		strcat(user_gitignore, "/.gitignore");
+		excludes_file = user_gitignore;
+	}
 	if (!access(path, R_OK))
 		add_excludes_from_file(dir, path);
-	if (excludes_file && !access(excludes_file, R_OK))
+	if (!access(excludes_file, R_OK))
 		add_excludes_from_file(dir, excludes_file);
 }
 
-- 
1.6.5.2.152.gbbe9e

Re: [PATCH] let core.excludesfile default to ~/.gitignore.

[Stefan Naewe]

On 11/20/2009 2:23 PM, Matthieu Moy wrote:
> It seems this is the value most users set, so let's make it the default.

I like the idea but would suggest to use ~/.gitexcludes instead.
That way it doesn't clash with .gitignore if your $HOME is 
under git-control.

Regards

Stefan
-- 
----------------------------------------------------------------
/dev/random says: INTERLACE: To tie two boots together.

Re: [PATCH] let core.excludesfile default to ~/.gitignore.

[David Aguilar]

On Fri, Nov 20, 2009 at 03:30:06PM +0100, Stefan Naewe wrote:
> On 11/20/2009 2:23 PM, Matthieu Moy wrote:
> > It seems this is the value most users set, so let's make it the default.
> 
> I like the idea but would suggest to use ~/.gitexcludes instead.
> That way it doesn't clash with .gitignore if your $HOME is 
> under git-control.
> 
> Regards
> 
> Stefan

I second this.  I also keep my $HOME in git.


-- 
		David

[PATCH v2] Let core.excludesfile default to ~/.gitexcludes.

[Matthieu Moy]

Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
is a sane default.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Change since v1 : just changed gitignore -> gitexcludes.

 Documentation/config.txt |    1 +
 dir.c                    |    9 ++++++++-
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 39d1226..13871a6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -384,6 +384,7 @@ core.excludesfile::
 	of files which are not meant to be tracked.  "~/" is expanded
 	to the value of `$HOME` and "~user/" to the specified user's
 	home directory.  See linkgit:gitignore[5].
+	Default: ~/.gitexcludes.
 
 core.editor::
 	Commands such as `commit` and `tag` that lets you edit
diff --git a/dir.c b/dir.c
index d0999ba..cf3d8b4 100644
--- a/dir.c
+++ b/dir.c
@@ -914,9 +914,16 @@ void setup_standard_excludes(struct dir_struct *dir)
 
 	dir->exclude_per_dir = ".gitignore";
 	path = git_path("info/exclude");
+	if (!excludes_file) {
+		const char *home = getenv("HOME");
+		char *user_gitignore = malloc(strlen(home) + strlen("/.gitexcludes") + 1);
+		strcpy(user_gitignore, home);
+		strcat(user_gitignore, "/.gitexcludes");
+		excludes_file = user_gitignore;
+	}
 	if (!access(path, R_OK))
 		add_excludes_from_file(dir, path);
-	if (excludes_file && !access(excludes_file, R_OK))
+	if (!access(excludes_file, R_OK))
 		add_excludes_from_file(dir, excludes_file);
 }
 
-- 
1.6.5.3.435.g5f2e3.dirty

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

[Matthieu Moy]

Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
is a sane default.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
(just resending since the patch seems to have got lost in the process)

 Documentation/config.txt |    1 +
 dir.c                    |    9 ++++++++-
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7ff2d1d..9fc527c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -408,6 +408,7 @@ core.excludesfile::
 	of files which are not meant to be tracked.  "{tilde}/" is expanded
 	to the value of `$HOME` and "{tilde}user/" to the specified user's
 	home directory.  See linkgit:gitignore[5].
+	Default: ~/.gitexcludes.
 
 core.editor::
 	Commands such as `commit` and `tag` that lets you edit
diff --git a/dir.c b/dir.c
index 3a8d3e6..a6a6291 100644
--- a/dir.c
+++ b/dir.c
@@ -944,9 +944,16 @@ void setup_standard_excludes(struct dir_struct *dir)
 
 	dir->exclude_per_dir = ".gitignore";
 	path = git_path("info/exclude");
+	if (!excludes_file) {
+		const char *home = getenv("HOME");
+		char *user_gitignore = malloc(strlen(home) + strlen("/.gitexcludes") + 1);
+		strcpy(user_gitignore, home);
+		strcat(user_gitignore, "/.gitexcludes");
+		excludes_file = user_gitignore;
+	}
 	if (!access(path, R_OK))
 		add_excludes_from_file(dir, path);
-	if (excludes_file && !access(excludes_file, R_OK))
+	if (!access(excludes_file, R_OK))
 		add_excludes_from_file(dir, excludes_file);
 }
 
-- 
1.6.5.3.435.g5f2e3.dirty

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

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
> is a sane default.

I'm sorry to jump in so late, and this may sound like bike-shedding, but
right now we have

.git/info/exclude
.gitignore

and this would add

~/.gitexcludes

That is, three terms, or two, where one comes in two variations
(exclude/exludes). I always wondered why we have two.

The reason for .gitignore is most probably the similarity to
.${othervcs}ignore, and that is a valid reason.

I know we have ~/.gitconfig for the global version of .git/config, and
maybe that was just no good idea either. But I don't even dare
suggesting to rename it ~/.gitglobalconfig.

So, in line at least with our term "global" (per user) config, I would
suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.

On a somewhat larger scale, a good alternative strategy would be to have
a directory "~/.gitglobal/" in which Git would look for
~/.gitglobal/config and
~/.gitglobal/info/ignore or
~/.gitglobal/ignore

i.e. mirroring the repo structure or at least bundling everything in a
single dir, which would also be a good place for a global svnauthors
file and such, and for other global configuration files we don't think
of right now.

Michael

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

[Paolo Bonzini]

On 11/26/2009 01:00 PM, Michael J Gruber wrote:
> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore
>
> and this would add
>
> ~/.gitexcludes
>
> That is, three terms, or two, where one comes in two variations
> (exclude/exludes). I always wondered why we have two.

Would you be fine with ~/.gitexclude?

Paolo

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

[Michael J Gruber]

Paolo Bonzini venit, vidit, dixit 26.11.2009 13:49:
> On 11/26/2009 01:00 PM, Michael J Gruber wrote:
>> I'm sorry to jump in so late, and this may sound like bike-shedding, but
>> right now we have
>>
>> .git/info/exclude
>> .gitignore
>>
>> and this would add
>>
>> ~/.gitexcludes
>>
>> That is, three terms, or two, where one comes in two variations
>> (exclude/exludes). I always wondered why we have two.
> 
> Would you be fine with ~/.gitexclude?

Not really. You see, a user tracking his $HOME will have a ~/.gitignore
and a ~/.gitexclude then. I think we should distinguish local and global
"config" files more systematically. Which is why I suggested the subdir,
or having global in the name.

Michael

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

[Bert Wesarg]

On Thu, Nov 26, 2009 at 13:00, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
>> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
>> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
>> is a sane default.
>
> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore
>
> and this would add
>
> ~/.gitexcludes
>
> That is, three terms, or two, where one comes in two variations
> (exclude/exludes). I always wondered why we have two.
>
> The reason for .gitignore is most probably the similarity to
> .${othervcs}ignore, and that is a valid reason.
>
> I know we have ~/.gitconfig for the global version of .git/config, and
> maybe that was just no good idea either. But I don't even dare
> suggesting to rename it ~/.gitglobalconfig.
>
> So, in line at least with our term "global" (per user) config, I would
> suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
> eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
>
> On a somewhat larger scale, a good alternative strategy would be to have
> a directory "~/.gitglobal/" in which Git would look for
> ~/.gitglobal/config and
> ~/.gitglobal/info/ignore or
> ~/.gitglobal/ignore
>
> i.e. mirroring the repo structure or at least bundling everything in a
> single dir, which would also be a good place for a global svnauthors
> file and such, and for other global configuration files we don't think
> of right now.
I would vote for that too. Its more future-proof than a single new
file. Also I would suggest to name this dir ~/.gitrc/. On the other
hand the --global option to git config specifies the .gitconfig in
your HOME.

Bert
>
> Michael

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

[Michael J Gruber]

Bert Wesarg venit, vidit, dixit 26.11.2009 14:01:
> On Thu, Nov 26, 2009 at 13:00, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
>>> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
>>> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
>>> is a sane default.
>>
>> I'm sorry to jump in so late, and this may sound like bike-shedding, but
>> right now we have
>>
>> .git/info/exclude
>> .gitignore
>>
>> and this would add
>>
>> ~/.gitexcludes
>>
>> That is, three terms, or two, where one comes in two variations
>> (exclude/exludes). I always wondered why we have two.
>>
>> The reason for .gitignore is most probably the similarity to
>> .${othervcs}ignore, and that is a valid reason.
>>
>> I know we have ~/.gitconfig for the global version of .git/config, and
>> maybe that was just no good idea either. But I don't even dare
>> suggesting to rename it ~/.gitglobalconfig.
>>
>> So, in line at least with our term "global" (per user) config, I would
>> suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
>> eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
>>
>> On a somewhat larger scale, a good alternative strategy would be to have
>> a directory "~/.gitglobal/" in which Git would look for
>> ~/.gitglobal/config and
>> ~/.gitglobal/info/ignore or
>> ~/.gitglobal/ignore
>>
>> i.e. mirroring the repo structure or at least bundling everything in a
>> single dir, which would also be a good place for a global svnauthors
>> file and such, and for other global configuration files we don't think
>> of right now.
> I would vote for that too. Its more future-proof than a single new
> file. Also I would suggest to name this dir ~/.gitrc/. 

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

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

[David Aguilar]

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

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

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore

The current dir.c::setup_standard_excludes() implementation reads exclude
patterns from "$GIT_DIR/info/exclude".  

As to the way forward regarding "info/exclude", my preference is to teach
the codepath to check if "info/ignore" exists, and read that after it
reads from "info/exclude" (to give the new file a slightly higher
precedence if both exist).

Document that we read from both info/ignore and info/exclude immediately
when this change happens.  The updated documentation probably should say
that "info/exclude" is still read and will be read forever, and tell the
readers that there is no difference in functionality between the two,
other than that "info/ignore" is a name that is more consistent with the
".gitignore" (which is the name of in-tree exclude patterns file).

And stop there.

While there is no reason to encourage new repositories to use info/exclude
over info/ignore, we shouldn't stop mentioning info/exclude or declare
deprecation in the documentation, as doing so would:

 (1) scare existing users that their info/exclude file may become invalid
     some day; and

 (2) puzzle new users (who inherited an already initialized repository
     that has been maintained by somebody else from the era before this
     change) what the info/exclude file in the repository is doing.

> and this would add
>
> ~/.gitexcludes
>
> That is, three terms, or two, where one comes in two variations
> (exclude/exludes). I always wondered why we have two.
>
> The reason for .gitignore is most probably the similarity to
> .${othervcs}ignore, and that is a valid reason.

I try not to get involved in bike-shedding (I removed myself from Cc), but
the events happened in the opposite order.

Originally we had the concept of "exclude patterns", in 9ff768e ([PATCH]
Give show-files the ability to process exclusion pattern., 2005-04-28).
This origin is still visible in the names of command line options to
"ls-files".  It was just a flat text file that is not tied to any
particular directory in the work tree.

Then much later in f87f949 (git-ls-files: --exclude mechanism updates.,
2005-07-24) the mechanism was extended, so that we could add per-directory
exclude patterns.  But that was just the _ability_; its actual use in the
Porcelains had to wait until ba966b9 (Teach git-status-script about
git-ls-files --others, 2005-08-26), and the commit finally established the
name ".gitignore" that is an in-tree, per-directory file that has exclude
patterns.  The name was inconsistent with the established concept of
"excluding", but was chosen to be similar to .scmignore.

Hopefully that would clear your wondering.

Re: [PATCH v2] Let core.excludesfile default to ~/.gitexcludes.

[Nanako Shiraishi]

Junio, could you tell us what happened to this thread?

Re: [PATCH v2] Let core.excludesfile default to ~/.gitexcludes.

[Matthieu Moy]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Junio, could you tell us what happened to this thread?

I'm not Junio, but I can try ...

Setting a default for core.excludesfile implies that changing it later
is hard. In particular, _if_ we chose one day to move from multiple
$HOME/.gitsomething files to $HOME/something-else/multiple-files
($XDG_CONFIG_HOME and $HOME/.gitglobal/{config,excludes,...} have been
suggested, as well as a $GIT_HOME variable), then the transition is
made harder by having a default.

So, while I think having a default is good, chosing the default
shouldn't be taken lightly.

I personally like the idea of a user config _directory_ with multiple
files in it, but I'm not clear on exactly what it should be, how the
transition plan would be, ...

So, I dropped the patch until we get closer to a consensus on what the
default value should be.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH v2] Let core.excludesfile default to ~/.gitexcludes.

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, could you tell us what happened to this thread?
>
> I'm not Junio, but I can try ...
> ...
> So, I dropped the patch until we get closer to a consensus on what the
> default value should be.

Thanks for status updates.  Should we start trying to reach a consensus on
how to move forward, or is it not your itch?

It is not _too_ bad to treat ~/.gitconfig specially and support reading
from ~/.$SOMEGITTTYNAME/{excludes,attributes} files.  We can also add
support for ~/.$SOMEGITTYNAME/config and try reading from it as well, but
even if we did so I don't think we should stop reading from ~/.gitconfig.

I don't have strong preference myself either way.

User-wide Git config directory (was Re: [PATCH v2] Let core.excludesfile default to ~/.gitexcludes.)

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Nanako Shiraishi <nanako3@lavabit.com> writes:
>>
>>> Junio, could you tell us what happened to this thread?
>>
>> I'm not Junio, but I can try ...
>> ...
>> So, I dropped the patch until we get closer to a consensus on what the
>> default value should be.
>
> Thanks for status updates.  Should we start trying to reach a consensus on
> how to move forward, or is it not your itch?

I wouldn't say it's not my itch. But I'm not sure I'm the best person
to do the job (job = comming close to a consensus, not writting the
code, which shouldn't be hard). Still, I can at least participate ;-).

> It is not _too_ bad to treat ~/.gitconfig specially and support reading
> from ~/.$SOMEGITTTYNAME/{excludes,attributes} files.

Let's throw in some ideas about what ~/$SOMEGITTTYNAME/ could be :

1) ~/.git/ => no, that would clash with people versioning their $HOME.

2) ~/.gitconfig/ => no, there's already a file ~/.gitconfig

3) ~/.gitglobal/ => that's an option.

4) ~/.config/git/ or, if set, $XDG_CONFIG_HOME/git/ (see
   http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html )
   => my prefered one, already discussed in a different context here :
   http://thread.gmane.org/gmane.comp.version-control.git/135447/focus=135559

Then, there's the question of what to put in this directory. I can see
two and a half options:

a) ~/.$SOMEGITTTYNAME/{excludes,attributes} as you propose.

a') ~/.$SOMEGITTTYNAME/{ignore,attributes} => I think "ignore" is the
   advertized vocabulary most of the time in porcelain, and "excludes"
   exists mostly for historical reasons.

b) ~/.$SOMEGITTTYNAME/<same thing as the content of $GIT_DIR>, that
   is:
   ~/.$SOMEGITTTYNAME/info/exclude
   ~/.$SOMEGITTTYNAME/info/attributes
   and perhaps
   ~/.$SOMEGITTTYNAME/config
   we could imagine also
   ~/.$SOMEGITTTYNAME/hooks

If I were really happy with the layout of $GIT_DIR, I'd vote for b)
for consistancy. But I'm not _that_ happy with it: why are exclude and
attributes not in the same directory as config? why is exclude
singular and attributes plural?

So, I dunno.

> We can also add support for ~/.$SOMEGITTYNAME/config and try reading
> from it as well, but even if we did so I don't think we should stop
> reading from ~/.gitconfig.

Yes, people having a ~/.gitconfig around should be able to continue to
use it (for years at least, and most likely forever).

And you're right to present it as a different problem. Perhaps we
should solve the problem above before starting debating about this
one.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] let core.excludesfile default to ~/.gitignore.

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> It seems this is the value most users set, so let's make it the default.

Maybe in 1.7.0, but I think using .gitignore will conflict with people who
put the entire $HOME under git (I think they are misguided, but that is
besides the point), so it should use some different name.