{"thread":{"id":"18741","subject":"[PATCH] Documentation: clarify .gitattributes search","startedAt":"2009-04-06T02:43:47Z","lastAt":"2009-04-06T18:59:45Z","messageCount":4,"participants":["Jason Merrill","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"110503","messageId":"49D96C63.9070200@redhat.com","threadId":"18741","inReplyTo":null,"subject":"[PATCH] Documentation: clarify .gitattributes search","fromName":"Jason Merrill","fromEmail":"jason@redhat.com","sentAt":"2009-04-06T02:43:47Z","receivedAt":"2009-04-06T02:43:47Z","isPatch":true,"sender":{"key":"jason@redhat.com","avatar":"https://avatars.githubusercontent.com/u/266146?v=4"},"body":"\n\n\n>From 04b504dc0c174d697cc1b75829fe2f7473f193ce Mon Sep 17 00:00:00 2001\nFrom: Jason Merrill \nDate: Sun, 5 Apr 2009 21:54:37 -0400\nSubject: [PATCH] Documentation: clarify .gitattributes search\n\n\nSigned-off-by: Jason Merrill \n---\nAs discussed on IRC today; I was wondering if my home directory qualified\nas a parent directory, but apparently not.\n\n Documentation/gitattributes.txt | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex 55668e3..0338385 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -60,9 +60,9 @@ same as in `.gitignore` files; see linkgit:gitignore[5].\n When deciding what attributes are assigned to a path, git\n consults `$GIT_DIR/info/attributes` file (which has the highest\n precedence), `.gitattributes` file in the same directory as the\n-path in question, and its parent directories (the further the\n-directory that contains `.gitattributes` is from the path in\n-question, the lower its precedence).\n+path in question, and its parent directories within the git repository\n+(the further the directory that contains `.gitattributes` is from the\n+path in question, the lower its precedence).\n \n If you wish to affect only a single repository (i.e., to assign\n attributes to files that are particular to one user's workflow), then\n-- \n1.6.2.2\n\n"},{"id":"110515","messageId":"7viqlicp1y.fsf@gitster.siamese.dyndns.org","threadId":"18741","inReplyTo":"49D96C63.9070200@redhat.com","subject":"Re: [PATCH] Documentation: clarify .gitattributes search","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-06T05:46:17Z","receivedAt":"2009-04-06T05:46:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jason Merrill writes:\n\n> From 04b504dc0c174d697cc1b75829fe2f7473f193ce Mon Sep 17 00:00:00 2001\n> From: Jason Merrill \n> Date: Sun, 5 Apr 2009 21:54:37 -0400\n> Subject: [PATCH] Documentation: clarify .gitattributes search\n\nYou do not want these four lines in the body of the message.\n\n> When deciding what attributes are assigned to a path, git\n> consults `$GIT_DIR/info/attributes` file (which has the highest\n> precedence), `.gitattributes` file in the same directory as the\n> -path in question, and its parent directories (the further the\n> -directory that contains `.gitattributes` is from the path in\n> -question, the lower its precedence).\n> +path in question, and its parent directories within the git repository\n> +(the further the directory that contains `.gitattributes` is from the\n> +path in question, the lower its precedence).\n\nI initially:\n\n (1) thought this was in \"it goes without saying\" category (but I am at\n fault here---losing git virginity long time ago);\n\n (2) also wondered why you were confused to think if your home directory\n (for that matter, any higher directory, like /.gitattributes at the\n filesystem root level) that is clearly outside of the project could\n possibly affect what happens inside a project; and\n\n (3) was puzzled why you do not have any patch to description of ignore\n files (perhaps you do not even a similar confusion on them).\n\nThe last point was interesting, because the documentation of gitignore\nuses this language:\n\n * Patterns read from a `.gitignore` file in the same directory\n as the path, or in any parent directory, with patterns in the\n higher level files (up to the root) being overridden by those in\n lower level files down to the directory containing the file.\n These patterns match relative to the location of the\n `.gitignore` file.\n\nSo \"up to the root\" might help. It might not.\n\nA few questions.\n\n (1) To a long-time git person, \"up to the root\" is obviously talking\n about the toplevel of the work tree, not \"root of the filesystem\",\n but is it clear to _you_ (or do you think it would be clear to\n somebody else without much previous exposure to git)?\n\n (2) If not, I think we should come up with a good wording and use that in\n both. How does the \"toplevel of the work tree\" sound for that\n purpose?\n\nI would want to avoid the word \"directories within the git repository\",\nbecause people would misinterpret that to mean directories like .git/refs\nand .git/objects/info, which is clearly not what you meant here.\n"},{"id":"110593","messageId":"49DA19C8.5010308@redhat.com","threadId":"18741","inReplyTo":"7viqlicp1y.fsf@gitster.siamese.dyndns.org","subject":"[PATCH v2] Documentation: clarify .gitattributes search","fromName":"Jason Merrill","fromEmail":"jason@redhat.com","sentAt":"2009-04-06T15:03:36Z","receivedAt":"2009-04-06T15:03:36Z","isPatch":true,"sender":{"key":"jason@redhat.com","avatar":"https://avatars.githubusercontent.com/u/266146?v=4"},"body":"Junio C Hamano wrote:\n> (2) also wondered why you were confused to think if your home directory\n> (for that matter, any higher directory, like /.gitattributes at the\n> filesystem root level) that is clearly outside of the project could\n> possibly affect what happens inside a project; and\n\nBecause it would be useful if it did; specifically, it would be \nconvenient to be able to say that ChangeLog files use \ngit-merge-changelog wherever they appear, and not have to repeat that in \nall my projects. I didn't really expect it, but thought that maybe it \nwas designed to work that way.\n\n> (3) was puzzled why you do not have any patch to description of ignore\n> files (perhaps you do not even a similar confusion on them).\n\nI hadn't really thought about them, but looking at the documentation now \nI see that ignore files have the core.excludesfile config variable to \nprovide global ignores; there doesn't seem to be anything analogous for \nattributes.\n\n> (1) To a long-time git person, \"up to the root\" is obviously talking\n> about the toplevel of the work tree, not \"root of the filesystem\",\n> but is it clear to _you_ (or do you think it would be clear to\n> somebody else without much previous exposure to git)?\n\nIt seems clear enough, as it would be pointless to say it if it meant \nthe root of the filesystem.\n\n> (2) If not, I think we should come up with a good wording and use that in\n> both. How does the \"toplevel of the work tree\" sound for that\n> purpose?\n\nSure, I'll use that.\n\n\n\n\nUse the term \"toplevel of the work tree\" in gitattributes.txt and\ngitignore.txt to define the limits of the search for those files.\n\nSigned-off-by: Jason Merrill \n---\n Documentation/gitattributes.txt | 6 +++---\n Documentation/gitignore.txt | 4 ++--\n 2 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex 55668e3..b762bba 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -60,9 +60,9 @@ same as in `.gitignore` files; see linkgit:gitignore[5].\n When deciding what attributes are assigned to a path, git\n consults `$GIT_DIR/info/attributes` file (which has the highest\n precedence), `.gitattributes` file in the same directory as the\n-path in question, and its parent directories (the further the\n-directory that contains `.gitattributes` is from the path in\n-question, the lower its precedence).\n+path in question, and its parent directories up to the toplevel of the\n+work tree (the further the directory that contains `.gitattributes`\n+is from the path in question, the lower its precedence).\n \n If you wish to affect only a single repository (i.e., to assign\n attributes to files that are particular to one user's workflow), then\ndiff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt\nindex 59321a2..7df3cef 100644\n--- a/Documentation/gitignore.txt\n+++ b/Documentation/gitignore.txt\n@@ -31,8 +31,8 @@ precedence, the last matching pattern decides the outcome):\n \n * Patterns read from a `.gitignore` file in the same directory\n as the path, or in any parent directory, with patterns in the\n- higher level files (up to the root) being overridden by those in\n- lower level files down to the directory containing the file.\n+ higher level files (up to the toplevel of the work tree) being overridden\n+ by those in lower level files down to the directory containing the file.\n These patterns match relative to the location of the\n `.gitignore` file. A project normally includes such\n `.gitignore` files in its repository, containing patterns for\n-- \n1.6.2.2\n\n"},{"id":"110616","messageId":"20090406185944.GB28120@coredump.intra.peff.net","threadId":"18741","inReplyTo":"49DA19C8.5010308@redhat.com","subject":"Re: [PATCH v2] Documentation: clarify .gitattributes search","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-06T18:59:45Z","receivedAt":"2009-04-06T18:59:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 06, 2009 at 11:03:36AM -0400, Jason Merrill wrote:\n\n> Junio C Hamano wrote:\n>> (2) also wondered why you were confused to think if your home directory\n>> (for that matter, any higher directory, like /.gitattributes at the\n>> filesystem root level) that is clearly outside of the project could\n>> possibly affect what happens inside a project; and\n>\n> Because it would be useful if it did; specifically, it would be \n> convenient to be able to say that ChangeLog files use git-merge-changelog \n> wherever they appear, and not have to repeat that in all my projects. I \n> didn't really expect it, but thought that maybe it was designed to work \n> that way.\n\nI don't think per-user attribute patterns are an unreasonable thing to\nwant, but I think traversing above the git worktree root is not a good\nway to implement it. Specifically:\n\n 1. It's inefficient. If your repo is only two directories deep, we now\n might look at 2 gitattributes files. But if you put your repo in\n /some/long/path/in/your/filesystem, we now have to check _each_ of\n those, even though they are very unlikely to contain gitattributes\n files.\n\n 2. It doesn't cover the per-user case very well. Repositories in your\n home directory and repositories in (for example) /tmp would need\n two separate gitattributes files.\n\nSpecifically checking $HOME/.gitattributes does make some sense to me\n(though perhaps it is worth giving it a different basename in case your\nhome directory actually is a git repository).\n\nThe argument against it would be that it is up to the repo to define the\n_types_ of its files, and for the user to define what to do with those\ntypes. But if you have many repos, I could certainly see it being\nconvenient to globally say \"for lack of better information, assume *.foo\nfiles are type foo\".\n\nAnd there is already some precedent, as you note, in core.excludesfile.\n\n-Peff\n"}]}