{"thread":{"id":"26997","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","startedAt":"2011-04-05T19:36:54Z","lastAt":"2011-04-05T21:51:01Z","messageCount":9,"participants":["Jonathan Nieder","Eric Blake","Junio C Hamano","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"165204","messageId":"1302032214-11438-1-git-send-email-eblake@redhat.com","threadId":"26997","inReplyTo":null,"subject":"[PATCH] Documentation: enhance gitignore whitelist example","fromName":"Eric Blake","fromEmail":"eblake@redhat.com","sentAt":"2011-04-05T19:36:54Z","receivedAt":"2011-04-05T19:36:54Z","isPatch":true,"sender":{"key":"eblake@redhat.com","avatar":"https://avatars.githubusercontent.com/u/32933908?v=4"},"body":"I was trying to whitelist a single file pattern in a directory\nthat I was otherwise content to ignore, but when I tried:\n\n/m4/\n!/m4/virt-*.m4\n\nthen 'git add' kept warning me that I had to use -f.  I finally\nfigured out that ignoring a directory is much different than ignoring\nall files in a directory, when it comes to later negation patterns:\n\n/m4/*\n!/m4/virt-*.m4\n\nImproving the documentation will help others learn from my mistake.\n\nSigned-off-by: Eric Blake <eblake@redhat.com>\n---\n Documentation/gitignore.txt |   19 +++++++++++++++++--\n 1 files changed, 17 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt\nindex 2e7328b..2f49989 100644\n--- a/Documentation/gitignore.txt\n+++ b/Documentation/gitignore.txt\n@@ -70,7 +70,9 @@ PATTERN FORMAT\n  - An optional prefix '!' which negates the pattern; any\n    matching file excluded by a previous pattern will become\n    included again.  If a negated pattern matches, this will\n-   override lower precedence patterns sources.\n+   override lower precedence patterns sources.  However, a\n+   file negation does not override a path that has already\n+   been excluded by a directory match.\n\n  - If the pattern ends with a slash, it is removed for the\n    purpose of the following description, but it would only find\n@@ -87,7 +89,8 @@ PATTERN FORMAT\n\n  - Otherwise, git treats the pattern as a shell glob suitable\n    for consumption by fnmatch(3) with the FNM_PATHNAME flag:\n-   wildcards in the pattern will not match a / in the pathname.\n+   wildcards in the pattern will not match a / in the pathname,\n+   and do not ignore files with a leading . in the pathname.\n    For example, \"Documentation/{asterisk}.html\" matches\n    \"Documentation/git.html\" but not \"Documentation/ppc/ppc.html\"\n    or \"tools/perf/Documentation/perf.html\".\n@@ -116,8 +119,11 @@ EXAMPLES\n     [...]\n     # Untracked files:\n     [...]\n+    #       Documentation/build\n     #       Documentation/foo.html\n     #       Documentation/gitignore.html\n+    #       build/log\n+    #       build/.file\n     #       file.o\n     #       lib.a\n     #       src/internal.o\n@@ -125,6 +131,10 @@ EXAMPLES\n     $ cat .git/info/exclude\n     # ignore objects and archives, anywhere in the tree.\n     *.[oa]\n+    # ignore files in the immediate child directory build,\n+    /build/*\n+    # except for the log.\n+    !/build/log\n     $ cat Documentation/.gitignore\n     # ignore generated html files,\n     *.html\n@@ -134,10 +144,15 @@ EXAMPLES\n     [...]\n     # Untracked files:\n     [...]\n+    #       Documentation/build\n     #       Documentation/foo.html\n+    #       build/log\n     [...]\n --------------------------------------------------------------\n\n+Note that using `!/build/log' works with an earlier `/build/*' but\n+would have no effect if there were an earlier `/build/'.\n+\n Another example:\n\n --------------------------------------------------------------\n-- \n1.7.4\n"},{"id":"165203","messageId":"20110405194005.GA32427@elie","threadId":"26997","inReplyTo":"1302032214-11438-1-git-send-email-eblake@redhat.com","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-05T19:40:05Z","receivedAt":"2011-04-05T19:40:05Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eric Blake wrote:\n\n> I was trying to whitelist a single file pattern in a directory\n> that I was otherwise content to ignore, but when I tried:\n> \n> /m4/\n> !/m4/virt-*.m4\n> \n> then 'git add' kept warning me that I had to use -f.  I finally\n> figured out that ignoring a directory is much different than ignoring\n> all files in a directory, when it comes to later negation patterns:\n> \n> /m4/*\n> !/m4/virt-*.m4\n> \n> Improving the documentation will help others learn from my mistake.\n> \n> Signed-off-by: Eric Blake <eblake@redhat.com>\n\nYes.\n\nAcked-by: Jonathan Nieder <jrnieder@gmail.com>\n\nCc-ing Hannes, in case he has thoughts on how to explain this more\nintuitively.\n\n> ---\n>  Documentation/gitignore.txt |   19 +++++++++++++++++--\n>  1 files changed, 17 insertions(+), 2 deletions(-)\n> \n> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt\n> index 2e7328b..2f49989 100644\n> --- a/Documentation/gitignore.txt\n> +++ b/Documentation/gitignore.txt\n> @@ -70,7 +70,9 @@ PATTERN FORMAT\n>   - An optional prefix '!' which negates the pattern; any\n>     matching file excluded by a previous pattern will become\n>     included again.  If a negated pattern matches, this will\n> -   override lower precedence patterns sources.\n> +   override lower precedence patterns sources.  However, a\n> +   file negation does not override a path that has already\n> +   been excluded by a directory match.\n> \n>   - If the pattern ends with a slash, it is removed for the\n>     purpose of the following description, but it would only find\n> @@ -87,7 +89,8 @@ PATTERN FORMAT\n> \n>   - Otherwise, git treats the pattern as a shell glob suitable\n>     for consumption by fnmatch(3) with the FNM_PATHNAME flag:\n> -   wildcards in the pattern will not match a / in the pathname.\n> +   wildcards in the pattern will not match a / in the pathname,\n> +   and do not ignore files with a leading . in the pathname.\n>     For example, \"Documentation/{asterisk}.html\" matches\n>     \"Documentation/git.html\" but not \"Documentation/ppc/ppc.html\"\n>     or \"tools/perf/Documentation/perf.html\".\n> @@ -116,8 +119,11 @@ EXAMPLES\n>      [...]\n>      # Untracked files:\n>      [...]\n> +    #       Documentation/build\n>      #       Documentation/foo.html\n>      #       Documentation/gitignore.html\n> +    #       build/log\n> +    #       build/.file\n>      #       file.o\n>      #       lib.a\n>      #       src/internal.o\n> @@ -125,6 +131,10 @@ EXAMPLES\n>      $ cat .git/info/exclude\n>      # ignore objects and archives, anywhere in the tree.\n>      *.[oa]\n> +    # ignore files in the immediate child directory build,\n> +    /build/*\n> +    # except for the log.\n> +    !/build/log\n>      $ cat Documentation/.gitignore\n>      # ignore generated html files,\n>      *.html\n> @@ -134,10 +144,15 @@ EXAMPLES\n>      [...]\n>      # Untracked files:\n>      [...]\n> +    #       Documentation/build\n>      #       Documentation/foo.html\n> +    #       build/log\n>      [...]\n>  --------------------------------------------------------------\n> \n> +Note that using `!/build/log' works with an earlier `/build/*' but\n> +would have no effect if there were an earlier `/build/'.\n> +\n>  Another example:\n> \n>  --------------------------------------------------------------\n> -- \n> 1.7.4\n> \n"},{"id":"165208","messageId":"7vfwpwmn8d.fsf@alter.siamese.dyndns.org","threadId":"26997","inReplyTo":"1302032214-11438-1-git-send-email-eblake@redhat.com","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-05T20:56:02Z","receivedAt":"2011-04-05T20:56:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Blake <eblake@redhat.com> writes:\n\n> I was trying to whitelist a single file pattern in a directory\n> that I was otherwise content to ignore, but when I tried:\n>\n> /m4/\n> !/m4/virt-*.m4\n\nPlease always indent displayed examples in commit log messages for\nreadability.\n\n> then 'git add' kept warning me that I had to use -f.  I finally\n> figured out that ignoring a directory is much different than ignoring\n> all files in a directory, when it comes to later negation patterns:\n>\n> /m4/*\n> !/m4/virt-*.m4\n>\n> Improving the documentation will help others learn from my mistake.\n>\n> Signed-off-by: Eric Blake <eblake@redhat.com>\n> ---\n>  Documentation/gitignore.txt |   19 +++++++++++++++++--\n>  1 files changed, 17 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt\n> index 2e7328b..2f49989 100644\n> --- a/Documentation/gitignore.txt\n> +++ b/Documentation/gitignore.txt\n> @@ -70,7 +70,9 @@ PATTERN FORMAT\n>   - An optional prefix '!' which negates the pattern; any\n>     matching file excluded by a previous pattern will become\n>     included again.  If a negated pattern matches, this will\n> -   override lower precedence patterns sources.\n> +   override lower precedence patterns sources.  However, a\n> +   file negation does not override a path that has already\n> +   been excluded by a directory match.\n\nIt may be better to say \"However X doesn't do Y\" than not saying anything,\nbut can't we phrase this more like \"If you want to do Y, you need to do Z\nalso/instead\"?  It would be much more useful for people who are looking\nfor a way to do Y if you didn't stop at saying \"X is not the way to do\nit\", and said \"Do X and Z if you want to achieve Y\", no?\n\nOn the other hand, if you are trying to explain why X doesn't do Y, the\nabove would need a bit more explanation (e.g. \"when a directory matches an\nignore pattern, it tells git not to descend into the directory to find\nignored or unignored paths in it\" or something like that).\n\n> @@ -125,6 +131,10 @@ EXAMPLES\n>      $ cat .git/info/exclude\n>      # ignore objects and archives, anywhere in the tree.\n>      *.[oa]\n> +    # ignore files in the immediate child directory build,\n> +    /build/*\n> +    # except for the log.\n> +    !/build/log\n\nIn the patch form it is clear these two lines go together, but the\ncorrespondence does not stand out in the text after the patch is applied.\n\nPerhaps doing it like this would make it clearer?\n\n> +    # ignore files in the immediate child directory build, ...\n> +    /build/*\n> +    # ... except for the log.\n> +    !/build/log\n"},{"id":"165213","messageId":"201104052315.54375.j6t@kdbg.org","threadId":"26997","inReplyTo":"20110405194005.GA32427@elie","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2011-04-05T21:15:54Z","receivedAt":"2011-04-05T21:15:54Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Dienstag, 5. April 2011, Jonathan Nieder wrote:\n> Eric Blake wrote:\n> > @@ -70,7 +70,9 @@ PATTERN FORMAT\n> >   - An optional prefix '!' which negates the pattern; any\n> >     matching file excluded by a previous pattern will become\n> >     included again.  If a negated pattern matches, this will\n> > -   override lower precedence patterns sources.\n> > +   override lower precedence patterns sources.  However, a\n> > +   file negation does not override a path that has already\n> > +   been excluded by a directory match.\n\nI don't think this is the right place to explain this caveat. Here we describe \nthe format and behavior of the patterns in a rather formal manner.\n\n> > @@ -87,7 +89,8 @@ PATTERN FORMAT\n> >\n> >   - Otherwise, git treats the pattern as a shell glob suitable\n> >     for consumption by fnmatch(3) with the FNM_PATHNAME flag:\n> > -   wildcards in the pattern will not match a / in the pathname.\n> > +   wildcards in the pattern will not match a / in the pathname,\n> > +   and do not ignore files with a leading . in the pathname.\n\nI don't think this is correct. * matches .gitignore. I tried it.\n\n> > @@ -116,8 +119,11 @@ EXAMPLES\n> >      [...]\n> >      # Untracked files:\n> >      [...]\n> > +    #       Documentation/build\n> >      #       Documentation/foo.html\n> >      #       Documentation/gitignore.html\n> > +    #       build/log\n> > +    #       build/.file\n> >      #       file.o\n> >      #       lib.a\n> >      #       src/internal.o\n> > @@ -125,6 +131,10 @@ EXAMPLES\n> >      $ cat .git/info/exclude\n> >      # ignore objects and archives, anywhere in the tree.\n> >      *.[oa]\n> > +    # ignore files in the immediate child directory build,\n> > +    /build/*\n> > +    # except for the log.\n> > +    !/build/log\n\nDoesn't this example give the false impression that you could do\n\n\t/foo/*\n\t!/foo/bar/baz\n\nand have foo/bar/baz not ignored? But it is still ignored.\n\nI propose a paragraph like this in the NOTES section:\n\n--- 8< ---\nWhen a directory is ignored, it is not possible to un-ignore a single file \nsomewhere in the directory using another pattern. E.g., with the patterns\n\n--------------\n/build/\n!/build/tests/results\n--------------\n\nthe file \"build/tests/results\" is still ignored because when a directory is \nignored, its contents are never investigated. In a situation where a few \nexceptions in an otherwise ignored hierarchy are needed, the recommended \nprocedure is to specify to ignore the root of the hierarchy and then to 'git \nadd -f' the exceptional files. Subsequent changes to the files will not be \nignored.\n--- 8< ---\n\n-- Hannes\n"},{"id":"165215","messageId":"4D9B8862.1050605@redhat.com","threadId":"26997","inReplyTo":"201104052315.54375.j6t@kdbg.org","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Eric Blake","fromEmail":"eblake@redhat.com","sentAt":"2011-04-05T21:23:46Z","receivedAt":"2011-04-05T21:23:46Z","isPatch":true,"sender":{"key":"eblake@redhat.com","avatar":"https://avatars.githubusercontent.com/u/32933908?v=4"},"body":"On 04/05/2011 03:15 PM, Johannes Sixt wrote:\n>>> @@ -87,7 +89,8 @@ PATTERN FORMAT\n>>>\n>>>   - Otherwise, git treats the pattern as a shell glob suitable\n>>>     for consumption by fnmatch(3) with the FNM_PATHNAME flag:\n>>> -   wildcards in the pattern will not match a / in the pathname.\n>>> +   wildcards in the pattern will not match a / in the pathname,\n>>> +   and do not ignore files with a leading . in the pathname.\n> \n> I don't think this is correct. * matches .gitignore. I tried it.\n\nThat was my point.  * _does_ match .gitignore, even though for normal\nshell globs, FNM_PERIOD is set and * does not match .gitignore.  That\nis, while in the shell 'dir/*' only matches non-dot files, in .gitignore\nit matches all files including dot-files.\n\nAny ideas for a better way to word that?\n\n> I propose a paragraph like this in the NOTES section:\n> \n> --- 8< ---\n> When a directory is ignored, it is not possible to un-ignore a single file \n> somewhere in the directory using another pattern. E.g., with the patterns\n> \n> --------------\n> /build/\n> !/build/tests/results\n> --------------\n> \n> the file \"build/tests/results\" is still ignored because when a directory is \n> ignored, its contents are never investigated. In a situation where a few \n> exceptions in an otherwise ignored hierarchy are needed, the recommended \n> procedure is to specify to ignore the root of the hierarchy and then to 'git \n> add -f' the exceptional files. Subsequent changes to the files will not be \n> ignored.\n\nYeah, but then you have to 'git add -f path/to/file' them every time you\nchange them, or use the sledgehammer of 'git add .'.\n\nDoes it make any better sense to document:\n\n  /build/*\n  !/build/*/\n  /build/*/*\n  !/build/foo/baz\n\nwhich ignores all files in build, then un-ignores directories, then\nignores all files in subdirectories of build except for the desired\nmulti-level file under build?  At which point you no longer need 'git\nadd -f', but can simply do 'git add build' to pick up /build/foo/baz in\none go without warning?\n\n-- \nEric Blake   eblake@redhat.com    +1-801-349-2682\nLibvirt virtualization library http://libvirt.org\n\n"},{"id":"165217","messageId":"7v4o6cml83.fsf@alter.siamese.dyndns.org","threadId":"26997","inReplyTo":"201104052315.54375.j6t@kdbg.org","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-05T21:39:24Z","receivedAt":"2011-04-05T21:39:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j6t@kdbg.org> writes:\n\n>> > @@ -87,7 +89,8 @@ PATTERN FORMAT\n>> >\n>> >   - Otherwise, git treats the pattern as a shell glob suitable\n>> >     for consumption by fnmatch(3) with the FNM_PATHNAME flag:\n>> > -   wildcards in the pattern will not match a / in the pathname.\n>> > +   wildcards in the pattern will not match a / in the pathname,\n>> > +   and do not ignore files with a leading . in the pathname.\n>\n> I don't think this is correct. * matches .gitignore. I tried it.\n\nIt is badly phrased to begin with.\n\nIt shouldn't say \"do not ignore\", which is determined by the presense or\nthe lack of the leading '!' before the pattern.  The pattern either\nmatches or does not match paths that begin with dot.\n\nI think we pass FNM_PATHNAME but not FNM_PERIOD, so * would match a period\nhence \".gitignore\".  What Eric wrote may be correct in the sense that \"the\npattern matcher does not _ignore_ .gitignore as not matching but catches it\nwith '*'\", but as the result the path ends up getting ignored ;-)\n\n> I propose a paragraph like this in the NOTES section:\n\nI think it makes sense to have something like that, but please state it\nlike \"to do Y, do X and Z\" (optionally followed by \"with just X, Y won't\nhappen because..., hence you need to do Z as well\"), instead of starting\nwith \"you cannot do Y with only X\".\n\nIOW, start from a positive and helpful recipe, and then explain why \"you\ncannot do Y with only X\" after that.\n\n> --- 8< ---\n> When a directory is ignored, it is not possible to un-ignore a single file \n> somewhere in the directory using another pattern. E.g., with the patterns\n>\n> --------------\n> /build/\n> !/build/tests/results\n> --------------\n>\n> the file \"build/tests/results\" is still ignored because when a directory is \n> ignored, its contents are never investigated. In a situation where a few \n> exceptions in an otherwise ignored hierarchy are needed, the recommended \n> procedure is to specify to ignore the root of the hierarchy and then to 'git \n> add -f' the exceptional files. Subsequent changes to the files will not be \n> ignored.\n> --- 8< ---\n"},{"id":"165218","messageId":"20110405214114.GA13729@elie","threadId":"26997","inReplyTo":"4D9B8862.1050605@redhat.com","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-05T21:41:14Z","receivedAt":"2011-04-05T21:41:14Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eric Blake wrote:\n\n> Yeah, but then you have to 'git add -f path/to/file' them every time you\n> change them\n\nNo, I don't believe that's true.\n\n $ git add -f git.o\n $ >git.o\n $ git add git.o\n\n.gitignore only protects against starting to track a file that was\npreviously untracked.\n\nI do tend to use exceptions in .gitignore anyway, since (1) it allows,\nas a sanity check,\n\n $ git ls-files -i --exclude-standard\n\nand (2) to import from or compare to a tarball, one can do\n\n $ git rm -rf .\n $ git add .\n"},{"id":"165219","messageId":"4D9B8E66.2010408@redhat.com","threadId":"26997","inReplyTo":"20110405214114.GA13729@elie","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Eric Blake","fromEmail":"eblake@redhat.com","sentAt":"2011-04-05T21:49:26Z","receivedAt":"2011-04-05T21:49:26Z","isPatch":true,"sender":{"key":"eblake@redhat.com","avatar":"https://avatars.githubusercontent.com/u/32933908?v=4"},"body":"On 04/05/2011 03:41 PM, Jonathan Nieder wrote:\n> Eric Blake wrote:\n> \n>> Yeah, but then you have to 'git add -f path/to/file' them every time you\n>> change them\n> \n> No, I don't believe that's true.\n> \n>  $ git add -f git.o\n>  $ >git.o\n>  $ git add git.o\n\nAha - it's that pesky dir/ vs. dir/* biting me, yet again:\n\n$ mkdir -p /tmp/blah\n$ cd /tmp/blah\n$ git init\nInitialized empty Git repository in /tmp/blah/.git/\n$ mkdir sub\n$ > sub/file\n$ git add sub/file\n$ git commit -a -m 'one'\n[master (root-commit) 645ee5a] one\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 sub/file\n$ printf 'sub/*\\n!sub/file\\n' > .gitignore\n$ touch sub/file2\n$ echo hi > sub/file\n$ git status\n# On branch master\n# Changes not staged for commit:\n#   (use \"git add <file>...\" to update what will be committed)\n#   (use \"git checkout -- <file>...\" to discard changes in working\ndirectory)\n#\n#\tmodified:   sub/file\n#\n# Untracked files:\n#   (use \"git add <file>...\" to include in what will be committed)\n#\n#\t.gitignore\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git add sub\n$ git status\n# On branch master\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#\n#\tmodified:   sub/file\n#\n# Untracked files:\n#   (use \"git add <file>...\" to include in what will be committed)\n#\n#\t.gitignore\n$ git reset\nUnstaged changes after reset:\nM\tsub/file\n$ printf 'sub/\\n!sub/file\\n' > .gitignore\n$ git add sub\nThe following paths are ignored by one of your .gitignore files:\nsub\nUse -f if you really want to add them.\nfatal: no files added\n$ git add sub/file\nThe following paths are ignored by one of your .gitignore files:\nsub\nUse -f if you really want to add them.\nfatal: no files added\n$ git status\n# On branch master\n# Changes not staged for commit:\n#   (use \"git add <file>...\" to update what will be committed)\n#   (use \"git checkout -- <file>...\" to discard changes in working\ndirectory)\n#\n#\tmodified:   sub/file\n#\n# Untracked files:\n#   (use \"git add <file>...\" to include in what will be committed)\n#\n#\t.gitignore\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git add .\n$ git status\n# On branch master\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#\n#\tnew file:   .gitignore\n#\tmodified:   sub/file\n#\n\n> \n> .gitignore only protects against starting to track a file that was\n> previously untracked.\n\nNot quite.  When filtering a directory, it also protects against changes\nto tracked files in that directory.  And that is what has been throwing\nme off, which is why we need a doc change (or possibly even a behavior\nchange).\n\n-- \nEric Blake   eblake@redhat.com    +1-801-349-2682\nLibvirt virtualization library http://libvirt.org\n\n"},{"id":"165220","messageId":"7vzko4l64a.fsf@alter.siamese.dyndns.org","threadId":"26997","inReplyTo":"4D9B8862.1050605@redhat.com","subject":"Re: [PATCH] Documentation: enhance gitignore whitelist example","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-05T21:51:01Z","receivedAt":"2011-04-05T21:51:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Blake <eblake@redhat.com> writes:\n\n> On 04/05/2011 03:15 PM, Johannes Sixt wrote:\n>>>> @@ -87,7 +89,8 @@ PATTERN FORMAT\n>>>>\n>>>>   - Otherwise, git treats the pattern as a shell glob suitable\n>>>>     for consumption by fnmatch(3) with the FNM_PATHNAME flag:\n>>>> -   wildcards in the pattern will not match a / in the pathname.\n>>>> +   wildcards in the pattern will not match a / in the pathname,\n>>>> +   and do not ignore files with a leading . in the pathname.\n>> \n>> I don't think this is correct. * matches .gitignore. I tried it.\n>\n> That was my point.  * _does_ match .gitignore, even though for normal\n> shell globs, FNM_PERIOD is set and * does not match .gitignore.  That\n> is, while in the shell 'dir/*' only matches non-dot files, in .gitignore\n> it matches all files including dot-files.\n>\n> Any ideas for a better way to word that?\n\nInstead of \"and do not ignore files with a leading\", say \"but will match\na dot '.'\".  You are talking about the rule for wildcards to match or not\nto match the pathname and there is no room for the word \"ignore\" to come\ninto play in this sentence.\n"}]}