On Mon, Apr 06, 2009 at 11:03:36AM -0400, Jason Merrill wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html