All of lore.kernel.org
 help / color / mirror / 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

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.