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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 26, 2009, 18:18 UTC
Message-ID: <7vmy2987zi.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>

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

Show 5 quoted lines

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

Show 9 quoted lines

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