Re: [PATCH v2] Documentation: clarify .gitattributes search

From: Jeff King <peff@peff.net>
Date: Apr 6, 2009, 18:59 UTC
Message-ID: <20090406185944.GB28120@coredump.intra.peff.net>
In-Reply-To: <49DA19C8.5010308@redhat.com>

On Mon, Apr 06, 2009 at 11:03:36AM -0400, Jason Merrill wrote:

Show 11 quoted lines

> Junio C Hamano wrote:
>>  (2) also wondered why you were confused to think if your home directory
>>      (for that matter, any higher directory, like /.gitattributes at the
>>      filesystem root level) that is clearly outside of the project could
>>      possibly affect what happens inside a project; and
>
> Because it would be useful if it did; specifically, it would be  
> convenient to be able to say that ChangeLog files use git-merge-changelog 
> wherever they appear, and not have to repeat that in all my projects.  I 
> didn't really expect it, but thought that maybe it was designed to work 
> that way.

I don't think per-user attribute patterns are an unreasonable thing to want, but I think traversing above the git worktree root is not a good way to implement it. Specifically:

  1. It's inefficient. If your repo is only two directories deep, we now
     might look at 2 gitattributes files. But if you put your repo in
     /some/long/path/in/your/filesystem, we now have to check _each_ of
     those, even though they are very unlikely to contain gitattributes
     files.

  2. It doesn't cover the per-user case very well. Repositories in your
     home directory and repositories in (for example) /tmp would need
     two separate gitattributes files.

Specifically checking $HOME/.gitattributes does make some sense to me (though perhaps it is worth giving it a different basename in case your home directory actually is a git repository).

The argument against it would be that it is up to the repo to define the _types_ of its files, and for the user to define what to do with those types. But if you have many repos, I could certainly see it being convenient to globally say "for lack of better information, assume *.foo files are type foo".

And there is already some precedent, as you note, in core.excludesfile.

-Peff