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

Michael J Gruber [off-list ref] 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.