git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: [PATCH v2] Documentation: clarify .gitattributes search
Date: Mon, 06 Apr 2009 11:03:36 -0400	[thread overview]
Message-ID: <49DA19C8.5010308@redhat.com> (raw)
In-Reply-To: <7viqlicp1y.fsf@gitster.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

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.

>  (3) was puzzled why you do not have any patch to description of ignore
>      files (perhaps you do not even a similar confusion on them).

I hadn't really thought about them, but looking at the documentation now 
I see that ignore files have the core.excludesfile config variable to 
provide global ignores; there doesn't seem to be anything analogous for 
attributes.

>  (1) To a long-time git person, "up to the root" is obviously talking
>      about the toplevel of the work tree, not "root of the filesystem",
>      but is it clear to _you_ (or do you think it would be clear to
>      somebody else without much previous exposure to git)?

It seems clear enough, as it would be pointless to say it if it meant 
the root of the filesystem.

>  (2) If not, I think we should come up with a good wording and use that in
>      both.  How does the "toplevel of the work tree" sound for that
>      purpose?

Sure, I'll use that.



[-- Attachment #2: 0001-Documentation-clarify-.gitattributes-search.patch --]
[-- Type: text/x-patch, Size: 2139 bytes --]

Use the term "toplevel of the work tree" in gitattributes.txt and
gitignore.txt to define the limits of the search for those files.

Signed-off-by: Jason Merrill <jason@redhat.com>
---
 Documentation/gitattributes.txt |    6 +++---
 Documentation/gitignore.txt     |    4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 55668e3..b762bba 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -60,9 +60,9 @@ same as in `.gitignore` files; see linkgit:gitignore[5].
 When deciding what attributes are assigned to a path, git
 consults `$GIT_DIR/info/attributes` file (which has the highest
 precedence), `.gitattributes` file in the same directory as the
-path in question, and its parent directories (the further the
-directory that contains `.gitattributes` is from the path in
-question, the lower its precedence).
+path in question, and its parent directories up to the toplevel of the
+work tree (the further the directory that contains `.gitattributes`
+is from the path in question, the lower its precedence).
 
 If you wish to affect only a single repository (i.e., to assign
 attributes to files that are particular to one user's workflow), then
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 59321a2..7df3cef 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -31,8 +31,8 @@ precedence, the last matching pattern decides the outcome):
 
  * Patterns read from a `.gitignore` file in the same directory
    as the path, or in any parent directory, with patterns in the
-   higher level files (up to the root) being overridden by those in
-   lower level files down to the directory containing the file.
+   higher level files (up to the toplevel of the work tree) being overridden
+   by those in lower level files down to the directory containing the file.
    These patterns match relative to the location of the
    `.gitignore` file.  A project normally includes such
    `.gitignore` files in its repository, containing patterns for
-- 
1.6.2.2


  reply	other threads:[~2009-04-06 15:06 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   ` Jason Merrill [this message]
2009-04-06 18:59     ` [PATCH v2] " Jeff King

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=49DA19C8.5010308@redhat.com \
    --to=jason@redhat.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).