From: Jeff King <peff@peff.net>
To: Jason Merrill <jason@redhat.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v2] Documentation: clarify .gitattributes search
Date: Mon, 6 Apr 2009 14:59:45 -0400 [thread overview]
Message-ID: <20090406185944.GB28120@coredump.intra.peff.net> (raw)
In-Reply-To: <49DA19C8.5010308@redhat.com>
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
prev parent reply other threads:[~2009-04-06 19:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 2:43 [PATCH] Documentation: clarify .gitattributes search Jason Merrill
2009-04-06 5:46 ` Junio C Hamano
2009-04-06 15:03 ` [PATCH v2] " Jason Merrill
2009-04-06 18:59 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090406185944.GB28120@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jason@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).