{"thread":{"id":"44915","subject":"[RFC 0/2] grep: make output consistent with revision syntax","startedAt":"2017-01-19T15:28:28Z","lastAt":"2017-01-24T20:50:55Z","messageCount":21,"participants":["Stefan Hajnoczi","Jeff King","Brandon Williams","Junio C Hamano","Phil Hord","Jakub Narębski","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"309727","messageId":"20170119150347.3484-1-stefanha@redhat.com","threadId":"44915","inReplyTo":null,"subject":"[RFC 0/2] grep: make output consistent with revision syntax","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-19T15:03:45Z","receivedAt":"2017-01-19T15:28:28Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"git-grep(1)'s output is not consistent with git-rev-parse(1) revision syntax.\n\nThis means you cannot take \"rev:path/to/file.c: foo();\" output from git-grep(1)\nand expect \"git show rev:path/to/file.c\" to work. See the individual patches\nfor examples of command-lines that produce invalid output.\n\nThis series is an incomplete attempt at solving the issue. I'm not familiar\nenough with the git codebase to propose a better solution. Perhaps someone is\ninterested in a proper fix?\n\nStefan Hajnoczi (2):\n grep: only add delimiter if there isn't one already\n grep: use '/' delimiter for paths\n\n builtin/grep.c | 7 ++++++-\n 1 file changed, 6 insertions(+), 1 deletion(-)\n\n-- \n2.9.3\n\n"},{"id":"309728","messageId":"20170119150347.3484-3-stefanha@redhat.com","threadId":"44915","inReplyTo":"20170119150347.3484-1-stefanha@redhat.com","subject":"[RFC 2/2] grep: use '/' delimiter for paths","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-19T15:03:47Z","receivedAt":"2017-01-19T15:28:40Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"If the tree contains a sub-directory then git-grep(1) output contains a\ncolon character instead of a path separator:\n\n $ git grep malloc v2.9.3:t\n v2.9.3:t:test-lib.sh:\tsetup_malloc_check () {\n $ git show v2.9.3:t:test-lib.sh\n fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3'\n\nThis patch attempts to use the correct delimiter:\n\n $ git grep malloc v2.9.3:t\n v2.9.3:t/test-lib.sh:\tsetup_malloc_check () {\n $ git show v2.9.3:t/test-lib.sh\n (success)\n\nThis patch does not cope with @{1979-02-26 18:30:00} syntax and treats\nit as a path because it contains colons.\n\nSigned-off-by: Stefan Hajnoczi \n---\n builtin/grep.c | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex 3643d8a..06f8b47 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -493,7 +493,8 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n \n \t\t\t/* Add a delimiter if there isn't one already */\n \t\t\tif (name[len - 1] != '/' && name[len - 1] != ':') {\n-\t\t\t\tstrbuf_addch(&base, ':');\n+\t\t\t\t/* rev: or rev:path/ */\n+\t\t\t\tstrbuf_addch(&base, strchr(name, ':') ? '/' : ':');\n \t\t\t}\n \t\t}\n \t\tinit_tree_desc(&tree, data, size);\n-- \n2.9.3\n\n"},{"id":"309729","messageId":"20170119150347.3484-2-stefanha@redhat.com","threadId":"44915","inReplyTo":"20170119150347.3484-1-stefanha@redhat.com","subject":"[RFC 1/2] grep: only add delimiter if there isn't one already","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-19T15:03:46Z","receivedAt":"2017-01-19T15:31:07Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"git-grep(1) output does not follow git's own syntax:\n\n $ git grep malloc v2.9.3:\n v2.9.3::Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc\n $ git show v2.9.3::Makefile\n fatal: Path ':Makefile' does not exist in 'v2.9.3'\n\nThis patch avoids emitting the unnecessary ':' delimiter if the name\nalready ends with ':' or '/':\n\n $ git grep malloc v2.9.3:\n v2.9.3:Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc\n $ git show v2.9.3:Makefile\n (succeeds)\n\nSigned-off-by: Stefan Hajnoczi \n---\n builtin/grep.c | 6 +++++-\n 1 file changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex 462e607..3643d8a 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -490,7 +490,11 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n \t\tstrbuf_init(&base, PATH_MAX + len + 1);\n \t\tif (len) {\n \t\t\tstrbuf_add(&base, name, len);\n-\t\t\tstrbuf_addch(&base, ':');\n+\n+\t\t\t/* Add a delimiter if there isn't one already */\n+\t\t\tif (name[len - 1] != '/' && name[len - 1] != ':') {\n+\t\t\t\tstrbuf_addch(&base, ':');\n+\t\t\t}\n \t\t}\n \t\tinit_tree_desc(&tree, data, size);\n \t\thit = grep_tree(opt, pathspec, &tree, &base, base.len,\n-- \n2.9.3\n\n"},{"id":"309739","messageId":"20170119165958.xtotlvdta7udqllb@sigill.intra.peff.net","threadId":"44915","inReplyTo":"20170119150347.3484-1-stefanha@redhat.com","subject":"Re: [RFC 0/2] grep: make output consistent with revision syntax","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-19T16:59:59Z","receivedAt":"2017-01-19T17:09:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 19, 2017 at 03:03:45PM +0000, Stefan Hajnoczi wrote:\n\n> git-grep(1)'s output is not consistent with git-rev-parse(1) revision syntax.\n> \n> This means you cannot take \"rev:path/to/file.c: foo();\" output from git-grep(1)\n> and expect \"git show rev:path/to/file.c\" to work. See the individual patches\n> for examples of command-lines that produce invalid output.\n\nI think this is a good goal.\n\nI couldn't immediately think of any cases where your patches would\nmisbehave, but my initial thought was that the \"/\" versus \":\"\ndistinction is about whether the initial object is a tree or a commit.\n\nYou do still have to special case the root tree (so \"v2.9.3:\" does not\nget any delimiter). I think \"ends in a colon\" is actually a reasonable\nway of determining that.\n\n> This series is an incomplete attempt at solving the issue. I'm not familiar\n> enough with the git codebase to propose a better solution. Perhaps someone is\n> interested in a proper fix?\n\nAre there cases you know that aren't covered by your patches?\n\n-Peff\n"},{"id":"309745","messageId":"20170119182633.GG10641@google.com","threadId":"44915","inReplyTo":"20170119165958.xtotlvdta7udqllb@sigill.intra.peff.net","subject":"Re: [RFC 0/2] grep: make output consistent with revision syntax","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-01-19T18:26:33Z","receivedAt":"2017-01-19T18:26:42Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 01/19, Jeff King wrote:\n> On Thu, Jan 19, 2017 at 03:03:45PM +0000, Stefan Hajnoczi wrote:\n> \n> > git-grep(1)'s output is not consistent with git-rev-parse(1) revision syntax.\n> > \n> > This means you cannot take \"rev:path/to/file.c: foo();\" output from git-grep(1)\n> > and expect \"git show rev:path/to/file.c\" to work. See the individual patches\n> > for examples of command-lines that produce invalid output.\n> \n> I think this is a good goal.\n\nI agree.\n\n> I couldn't immediately think of any cases where your patches would\n> misbehave, but my initial thought was that the \"/\" versus \":\"\n> distinction is about whether the initial object is a tree or a commit.\n\nI think this is also the case, I couldn't think of another case where\nthis decision wasn't based on if the object is a tree or a commit.\nInterestingly enough I don't think we have any tests that exist that\ntest the formatting of grep's output when given a tree object since the\ntest suite still passes with these changes in. Which means this fix\nshould probably include a couple tests to ensure there's no regression\nin the future.\n\n-- \nBrandon Williams\n"},{"id":"309753","messageId":"xmqqtw8u28u1.fsf@gitster.mtv.corp.google.com","threadId":"44915","inReplyTo":"20170119150347.3484-2-stefanha@redhat.com","subject":"Re: [RFC 1/2] grep: only add delimiter if there isn't one already","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-19T18:39:02Z","receivedAt":"2017-01-19T18:40:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Hajnoczi writes:\n\n> git-grep(1) output does not follow git's own syntax:\n>\n> $ git grep malloc v2.9.3:\n> v2.9.3::Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc\n> $ git show v2.9.3::Makefile\n> fatal: Path ':Makefile' does not exist in 'v2.9.3'\n>\n> This patch avoids emitting the unnecessary ':' delimiter if the name\n> already ends with ':' or '/':\n>\n> $ git grep malloc v2.9.3:\n> v2.9.3:Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc\n> $ git show v2.9.3:Makefile\n> (succeeds)\n\nI am mildly negative on this one. I suspect that the above example\nis a made-up one and you might have a more compelling real-world use\ncase in mind, but at least the above does not convince me.\n\nThe end-user explicitly gave the extra ':' because she wanted to\nfeed the tree object, not a tag that leads to the tree, for some\nreason. I think the output should respect that and show how she\nspelled the starting point. IOW, it is not \"':' added unnecessarily\nby Git\". It is ':' added by the end-user for whatever reason.\n\n>\n> Signed-off-by: Stefan Hajnoczi \n> ---\n> builtin/grep.c | 6 +++++-\n> 1 file changed, 5 insertions(+), 1 deletion(-)\n>\n> diff --git a/builtin/grep.c b/builtin/grep.c\n> index 462e607..3643d8a 100644\n> --- a/builtin/grep.c\n> +++ b/builtin/grep.c\n> @@ -490,7 +490,11 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n> \t\tstrbuf_init(&base, PATH_MAX + len + 1);\n> \t\tif (len) {\n> \t\t\tstrbuf_add(&base, name, len);\n> -\t\t\tstrbuf_addch(&base, ':');\n> +\n> +\t\t\t/* Add a delimiter if there isn't one already */\n> +\t\t\tif (name[len - 1] != '/' && name[len - 1] != ':') {\n> +\t\t\t\tstrbuf_addch(&base, ':');\n> +\t\t\t}\n> \t\t}\n> \t\tinit_tree_desc(&tree, data, size);\n> \t\thit = grep_tree(opt, pathspec, &tree, &base, base.len,\n"},{"id":"309754","messageId":"xmqqpoji2851.fsf@gitster.mtv.corp.google.com","threadId":"44915","inReplyTo":"20170119150347.3484-3-stefanha@redhat.com","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-19T18:54:02Z","receivedAt":"2017-01-19T19:03:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Hajnoczi writes:\n\n> If the tree contains a sub-directory then git-grep(1) output contains a\n> colon character instead of a path separator:\n>\n> $ git grep malloc v2.9.3:t\n> v2.9.3:t:test-lib.sh:\tsetup_malloc_check () {\n> $ git show v2.9.3:t:test-lib.sh\n> fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3'\n\nI am slightly less negative on this compared to 1/2, but not by a\nbig margin. The user wanted to feed a subtree to the command,\ninstead of doing the more natural\n\n $ git grep -e malloc v2.9.3 -- t\n\nSo again, \"contains a colon character\" is not coming from what Git\ndoes, but the user gave Git \"a colon character\" when she didn't have\nto.\n\nHaving said that, if we wanted to start ignoring what the end-user\nsaid in the initial input like 1/2 and 2/2 does (i.e. \"this specific\ntree object\" as an input), I think the approach to solve for 1/2 and\n2/2 should be the same. I think we should decide to do a slash\ninstead of a colon, not because v2.9.3: has colon at the end and\nv2.9.3:t has colon in it, but because both of these are both bare\ntree objects. The patches presented does not seem to base their\ndecision on the actual object type but on the textual input, which\nseems wrong.\n"},{"id":"309756","messageId":"20170119182934.GH10641@google.com","threadId":"44915","inReplyTo":"20170119150347.3484-3-stefanha@redhat.com","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-01-19T18:29:34Z","receivedAt":"2017-01-19T19:03:23Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 01/19, Stefan Hajnoczi wrote:\n> If the tree contains a sub-directory then git-grep(1) output contains a\n> colon character instead of a path separator:\n> \n> $ git grep malloc v2.9.3:t\n> v2.9.3:t:test-lib.sh:\tsetup_malloc_check () {\n> $ git show v2.9.3:t:test-lib.sh\n> fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3'\n> \n> This patch attempts to use the correct delimiter:\n> \n> $ git grep malloc v2.9.3:t\n> v2.9.3:t/test-lib.sh:\tsetup_malloc_check () {\n> $ git show v2.9.3:t/test-lib.sh\n> (success)\n> \n> This patch does not cope with @{1979-02-26 18:30:00} syntax and treats\n> it as a path because it contains colons.\n> \n> Signed-off-by: Stefan Hajnoczi \n> ---\n> builtin/grep.c | 3 ++-\n> 1 file changed, 2 insertions(+), 1 deletion(-)\n> \n> diff --git a/builtin/grep.c b/builtin/grep.c\n> index 3643d8a..06f8b47 100644\n> --- a/builtin/grep.c\n> +++ b/builtin/grep.c\n> @@ -493,7 +493,8 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n> \n> \t\t\t/* Add a delimiter if there isn't one already */\n> \t\t\tif (name[len - 1] != '/' && name[len - 1] != ':') {\n> -\t\t\t\tstrbuf_addch(&base, ':');\n> +\t\t\t\t/* rev: or rev:path/ */\n> +\t\t\t\tstrbuf_addch(&base, strchr(name, ':') ? '/' : ':');\n\nAs Jeff mentioned it may be better to base which character gets appended\nby checking the obj->type field like this maybe:\n\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex 69dab5dc5..9dfe11dc7 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -495,7 +495,8 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n \t\t\t/* Add a delimiter if there isn't one already */\n \t\t\tif (name[len - 1] != '/' && name[len - 1] != ':') {\n \t\t\t\t/* rev: or rev:path/ */\n-\t\t\t\tstrbuf_addch(&base, strchr(name, ':') ? '/' : ':');\n+\t\t\t\tchar del = obj->type == OBJ_COMMIT ? ':' : '/';\n+\t\t\t\tstrbuf_addch(&base, del);\n \t\t\t}\n \t\t}\n \t\tinit_tree_desc(&tree, data, size);\n\n-- \nBrandon Williams\n"},{"id":"309828","messageId":"20170120135612.GB17499@stefanha-x1.localdomain","threadId":"44915","inReplyTo":"xmqqtw8u28u1.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC 1/2] grep: only add delimiter if there isn't one already","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-20T13:56:12Z","receivedAt":"2017-01-20T13:56:20Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"On Thu, Jan 19, 2017 at 10:39:02AM -0800, Junio C Hamano wrote:\n> Stefan Hajnoczi writes:\n> \n> > git-grep(1) output does not follow git's own syntax:\n> >\n> > $ git grep malloc v2.9.3:\n> > v2.9.3::Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc\n> > $ git show v2.9.3::Makefile\n> > fatal: Path ':Makefile' does not exist in 'v2.9.3'\n> >\n> > This patch avoids emitting the unnecessary ':' delimiter if the name\n> > already ends with ':' or '/':\n> >\n> > $ git grep malloc v2.9.3:\n> > v2.9.3:Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc\n> > $ git show v2.9.3:Makefile\n> > (succeeds)\n> \n> I am mildly negative on this one. I suspect that the above example\n> is a made-up one and you might have a more compelling real-world use\n> case in mind, but at least the above does not convince me.\n\nAnother trailing delimiter example:\n\n $ git grep malloc v2.9.3:t/\n v2.9.3:t/:test-lib.sh: setup_malloc_check () {\n\nAfter Patch 1/2:\n\n v2.9.3:t/test-lib.sh: setup_malloc_check () {\n\n> The end-user explicitly gave the extra ':' because she wanted to\n> feed the tree object, not a tag that leads to the tree, for some\n> reason. I think the output should respect that and show how she\n> spelled the starting point. IOW, it is not \"':' added unnecessarily\n> by Git\". It is ':' added by the end-user for whatever reason.\n\nv2.9.3::Makefile may convey that the user originally provided v2.9.3:\nbut is that actually useful information? I don't see what the user will\ndo with this information (and they should already know since they\nprovided the command-line).\n\nv2.9.3:Makefile can be copy-pasted or extracted by scripts for further\ngit commands. That is useful.\n\nStefan\n"},{"id":"309829","messageId":"20170120141212.GC17499@stefanha-x1.localdomain","threadId":"44915","inReplyTo":"xmqqpoji2851.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-20T14:12:12Z","receivedAt":"2017-01-20T14:12:26Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"On Thu, Jan 19, 2017 at 10:54:02AM -0800, Junio C Hamano wrote:\n> Stefan Hajnoczi writes:\n> \n> > If the tree contains a sub-directory then git-grep(1) output contains a\n> > colon character instead of a path separator:\n> >\n> > $ git grep malloc v2.9.3:t\n> > v2.9.3:t:test-lib.sh:\tsetup_malloc_check () {\n> > $ git show v2.9.3:t:test-lib.sh\n> > fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3'\n> \n> I am slightly less negative on this compared to 1/2, but not by a\n> big margin. The user wanted to feed a subtree to the command,\n> instead of doing the more natural\n> \n> $ git grep -e malloc v2.9.3 -- t\n\nI find : vs -- confusing:\n\n | : | -- \n ----------+----------------------+---------------------\n git grep | OK | OK\n ----------+----------------------+---------------------\n git show | OK | ignored\n ----------+----------------------+---------------------\n git log | no output | OK\n ----------+----------------------+---------------------\n\nNeither syntax always does what I expect. If git show -- \nhonored then I could use that syntax consistently.\n\nSorry for going on a tangent. Does it seem reasonable to handle \nin git-show(1) as a UI convenience?\n\n> So again, \"contains a colon character\" is not coming from what Git\n> does, but the user gave Git \"a colon character\" when she didn't have\n> to.\n> \n> Having said that, if we wanted to start ignoring what the end-user\n> said in the initial input like 1/2 and 2/2 does (i.e. \"this specific\n> tree object\" as an input), I think the approach to solve for 1/2 and\n> 2/2 should be the same. I think we should decide to do a slash\n> instead of a colon, not because v2.9.3: has colon at the end and\n> v2.9.3:t has colon in it, but because both of these are both bare\n> tree objects. The patches presented does not seem to base their\n> decision on the actual object type but on the textual input, which\n> seems wrong.\n\nYes, reparsing the name is ugly and I hoped to get feedback with this\nRFC. Thanks for the quick review!\n"},{"id":"309830","messageId":"20170120141710.GD17499@stefanha-x1.localdomain","threadId":"44915","inReplyTo":"20170119182934.GH10641@google.com","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-20T14:17:10Z","receivedAt":"2017-01-20T14:17:36Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"On Thu, Jan 19, 2017 at 10:29:34AM -0800, Brandon Williams wrote:\n> On 01/19, Stefan Hajnoczi wrote:\n> > If the tree contains a sub-directory then git-grep(1) output contains a\n> > colon character instead of a path separator:\n> > \n> > $ git grep malloc v2.9.3:t\n> > v2.9.3:t:test-lib.sh:\tsetup_malloc_check () {\n> > $ git show v2.9.3:t:test-lib.sh\n> > fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3'\n> > \n> > This patch attempts to use the correct delimiter:\n> > \n> > $ git grep malloc v2.9.3:t\n> > v2.9.3:t/test-lib.sh:\tsetup_malloc_check () {\n> > $ git show v2.9.3:t/test-lib.sh\n> > (success)\n> > \n> > This patch does not cope with @{1979-02-26 18:30:00} syntax and treats\n> > it as a path because it contains colons.\n> > \n> > Signed-off-by: Stefan Hajnoczi \n> > ---\n> > builtin/grep.c | 3 ++-\n> > 1 file changed, 2 insertions(+), 1 deletion(-)\n> > \n> > diff --git a/builtin/grep.c b/builtin/grep.c\n> > index 3643d8a..06f8b47 100644\n> > --- a/builtin/grep.c\n> > +++ b/builtin/grep.c\n> > @@ -493,7 +493,8 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n> > \n> > \t\t\t/* Add a delimiter if there isn't one already */\n> > \t\t\tif (name[len - 1] != '/' && name[len - 1] != ':') {\n> > -\t\t\t\tstrbuf_addch(&base, ':');\n> > +\t\t\t\t/* rev: or rev:path/ */\n> > +\t\t\t\tstrbuf_addch(&base, strchr(name, ':') ? '/' : ':');\n> \n> As Jeff mentioned it may be better to base which character gets appended\n> by checking the obj->type field like this maybe:\n> \n> diff --git a/builtin/grep.c b/builtin/grep.c\n> index 69dab5dc5..9dfe11dc7 100644\n> --- a/builtin/grep.c\n> +++ b/builtin/grep.c\n> @@ -495,7 +495,8 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n> \t\t\t/* Add a delimiter if there isn't one already */\n> \t\t\tif (name[len - 1] != '/' && name[len - 1] != ':') {\n> \t\t\t\t/* rev: or rev:path/ */\n> -\t\t\t\tstrbuf_addch(&base, strchr(name, ':') ? '/' : ':');\n> +\t\t\t\tchar del = obj->type == OBJ_COMMIT ? ':' : '/';\n> +\t\t\t\tstrbuf_addch(&base, del);\n\nNice, that also solves the false positive with @{1979-02-26 18:30:00}.\n\nStefan\n"},{"id":"309831","messageId":"20170120141832.GE17499@stefanha-x1.localdomain","threadId":"44915","inReplyTo":"20170119165958.xtotlvdta7udqllb@sigill.intra.peff.net","subject":"Re: [RFC 0/2] grep: make output consistent with revision syntax","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-20T14:18:32Z","receivedAt":"2017-01-20T14:25:17Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"On Thu, Jan 19, 2017 at 11:59:59AM -0500, Jeff King wrote:\n> On Thu, Jan 19, 2017 at 03:03:45PM +0000, Stefan Hajnoczi wrote:\n> \n> > git-grep(1)'s output is not consistent with git-rev-parse(1) revision syntax.\n> > \n> > This means you cannot take \"rev:path/to/file.c: foo();\" output from git-grep(1)\n> > and expect \"git show rev:path/to/file.c\" to work. See the individual patches\n> > for examples of command-lines that produce invalid output.\n> \n> I think this is a good goal.\n> \n> I couldn't immediately think of any cases where your patches would\n> misbehave, but my initial thought was that the \"/\" versus \":\"\n> distinction is about whether the initial object is a tree or a commit.\n> \n> You do still have to special case the root tree (so \"v2.9.3:\" does not\n> get any delimiter). I think \"ends in a colon\" is actually a reasonable\n> way of determining that.\n> \n> > This series is an incomplete attempt at solving the issue. I'm not familiar\n> > enough with the git codebase to propose a better solution. Perhaps someone is\n> > interested in a proper fix?\n> \n> Are there cases you know that aren't covered by your patches?\n\nFrom Patch 2/2:\n\n This patch does not cope with @{1979-02-26 18:30:00} syntax and treats\n it as a path because it contains colons.\n\nIf we use obj->type instead of re-parsing the name then that problem is\nsolved.\n"},{"id":"309832","messageId":"20170120141954.xyocl6oqoykqmpl5@sigill.intra.peff.net","threadId":"44915","inReplyTo":"20170120141212.GC17499@stefanha-x1.localdomain","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-20T14:19:55Z","receivedAt":"2017-01-20T14:26:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 20, 2017 at 02:12:12PM +0000, Stefan Hajnoczi wrote:\n\n> I find : vs -- confusing:\n> \n> | : | -- \n> ----------+----------------------+---------------------\n> git grep | OK | OK\n> ----------+----------------------+---------------------\n> git show | OK | ignored\n> ----------+----------------------+---------------------\n> git log | no output | OK\n> ----------+----------------------+---------------------\n> \n> Neither syntax always does what I expect. If git show -- \n> honored then I could use that syntax consistently.\n> \n> Sorry for going on a tangent. Does it seem reasonable to handle \n> in git-show(1) as a UI convenience?\n\nIt's not ignored; just as with git-log, it's a pathspec to limit the\ndiff. E.g.:\n\n $ git show --name-status v2.9.3\n ...\n M Documentation/RelNotes/2.9.3.txt\n M Documentation/git.txt\n M GIT-VERSION-GEN\n\n $ git show --name-status v2.9.3 -- Documentation\n M Documentation/RelNotes/2.9.3.txt\n M Documentation/git.txt\n\nThat's typically less useful than it is with log (where limiting the\ndiff also kicks in history simplification and omits some commits\nentirely). But it does do something.\n\n-Peff\n"},{"id":"309834","messageId":"20170120143230.t4wwzp3ubigwupgq@sigill.intra.peff.net","threadId":"44915","inReplyTo":"20170120141832.GE17499@stefanha-x1.localdomain","subject":"Re: [RFC 0/2] grep: make output consistent with revision syntax","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-20T14:32:30Z","receivedAt":"2017-01-20T14:33:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 20, 2017 at 02:18:32PM +0000, Stefan Hajnoczi wrote:\n\n> > Are there cases you know that aren't covered by your patches?\n> \n> From Patch 2/2:\n> \n> This patch does not cope with @{1979-02-26 18:30:00} syntax and treats\n> it as a path because it contains colons.\n> \n> If we use obj->type instead of re-parsing the name then that problem is\n> solved.\n\nAh, right. I somehow totally missed that, and blindly assumed your colon\nsearch was only at the end. But of course that wouldn't work at all (it\nwould miss \"v2.9.3:t\").\n\nSo yes, definitely it should be checking the object type.\n\n-Peff\n"},{"id":"309845","messageId":"xmqqlgu5y4u8.fsf@gitster.mtv.corp.google.com","threadId":"44915","inReplyTo":"20170120135612.GB17499@stefanha-x1.localdomain","subject":"Re: [RFC 1/2] grep: only add delimiter if there isn't one already","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-20T18:16:31Z","receivedAt":"2017-01-20T18:16:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Hajnoczi writes:\n\n> v2.9.3::Makefile may convey that the user originally provided v2.9.3:\n> but is that actually useful information?\n\nYou are either asking a wrong question, or asking a wrong person\n(i.e. Git) the question. The real question is why the user added a\ncolon at the end, when \"v2.9.3\" alone would have sufficed. What did\nthe user want to get out of giving an extra colon like \"v2.9.3:\"?\n\nOne answer I can think of is that it is a degenerate case of [2/2],\ni.e. if \"v2.9.3:t\" were an appropriate way to look in the subtree\n\"t\" of \"v2.9.3\", \"v2.9.3:\" would be the appropriate way to look in\nthe whole tree of \"v2.9.3\".\n\nI understand, from your response to my comment in the thread for\n[2/2], that the reason why \"v2.9.3:t\" was used in the example was\nbecause you felt uncomfortable with using pathspec. \n\nThat's superstition.\n\nMy only piece of advice to folks who feel that way is to learn Git\nmore and get comfortable. You can do neat things like\n\n $ git grep -e pattern rev -- t ':!t/helper/'\n\nthat you cannot do with \"rev:t\", for example ;-)\n\nAll examples we saw so far are the ones that the user used the colon\nsyntax when it is more natural to express the command without it. I\nam hesitant to see the behaviour of the command changed to appease\nsuch suboptimal use cases if it requires us to discard a bit of\ninformation, when we haven't established it is OK to lose.\n\nThere may be a case\n\n (1) where the colon syntax is the most natural thing to use, AND\n script reading the output that used that syntax is forced to do\n unnecessary work because \"git grep\" parrots the colon\n literally, instread of being more intelligent about it\n (i.e. omitting or substituting with slash when the input is a\n tree object, not a tree-ish, as discussed in the thread).\n\n (2) where the colon syntax is the most natural thing, AND script\n reading the output WANTS to see the distinction in the input\n (remember, \"git grep\" can take more than one input tree).\n\nWe haven't seen either of the above two in the discussion, so the\ndiscussion so far is not sufficient to support the change being\nproposed in this RFC, which requires that it is safe to assume that\n(1) is the only case where the input is a raw tree (or the input\ncontains a colon) and (2) will never happen.\n\nSo I am still mildly negative on the whole thing.\n"},{"id":"309869","messageId":"xmqq60l9wdb9.fsf@gitster.mtv.corp.google.com","threadId":"44915","inReplyTo":"20170120141954.xyocl6oqoykqmpl5@sigill.intra.peff.net","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-20T22:56:26Z","receivedAt":"2017-01-20T22:57:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> It's not ignored; just as with git-log, it's a pathspec to limit the\n> diff. E.g.:\n>\n> $ git show --name-status v2.9.3\n> ...\n> M Documentation/RelNotes/2.9.3.txt\n> M Documentation/git.txt\n> M GIT-VERSION-GEN\n>\n> $ git show --name-status v2.9.3 -- Documentation\n> M Documentation/RelNotes/2.9.3.txt\n> M Documentation/git.txt\n>\n> That's typically less useful than it is with log (where limiting the\n> diff also kicks in history simplification and omits some commits\n> entirely). But it does do something.\n\nI think Stefan is missing the fact that the argument to \"git show\n:\" actually is naming a blob that sits at the \nin the . In other words, \"show\" is acting as a glorified\n\"git -p cat-file blob\", in that use.\n\nThe use of \"git show\" you are demonstrating is still about showing\nthe commit object, whose behaviour is defined to show the log\nmessage and the diff relative to its sole parent, limited to the\npaths that match the pathspec.\n\nIt is perfectly fine and desirable that \"git show :\"\nand \"git show -- \" behaves differently. These are\ntwo completely different features.\n\n\n"},{"id":"310079","messageId":"20170123131551.GL29186@stefanha-x1.localdomain","threadId":"44915","inReplyTo":"xmqqlgu5y4u8.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC 1/2] grep: only add delimiter if there isn't one already","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-23T13:15:51Z","receivedAt":"2017-01-24T09:54:01Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:\n> Stefan Hajnoczi writes:\n> \n> > v2.9.3::Makefile may convey that the user originally provided v2.9.3:\n> > but is that actually useful information?\n> \n> You are either asking a wrong question, or asking a wrong person\n> (i.e. Git) the question. The real question is why the user added a\n> colon at the end, when \"v2.9.3\" alone would have sufficed. What did\n> the user want to get out of giving an extra colon like \"v2.9.3:\"?\n> \n> One answer I can think of is that it is a degenerate case of [2/2],\n> i.e. if \"v2.9.3:t\" were an appropriate way to look in the subtree\n> \"t\" of \"v2.9.3\", \"v2.9.3:\" would be the appropriate way to look in\n> the whole tree of \"v2.9.3\".\n> \n> I understand, from your response to my comment in the thread for\n> [2/2], that the reason why \"v2.9.3:t\" was used in the example was\n> because you felt uncomfortable with using pathspec. \n> \n> That's superstition.\n> \n> My only piece of advice to folks who feel that way is to learn Git\n> more and get comfortable. You can do neat things like\n> \n> $ git grep -e pattern rev -- t ':!t/helper/'\n> \n> that you cannot do with \"rev:t\", for example ;-)\n\nNeat, thanks for showing the path exclusion syntax. I wasn't aware of\nit.\n\n> All examples we saw so far are the ones that the user used the colon\n> syntax when it is more natural to express the command without it. I\n> am hesitant to see the behaviour of the command changed to appease\n> such suboptimal use cases if it requires us to discard a bit of\n> information, when we haven't established it is OK to lose.\n> \n> There may be a case\n> \n> (1) where the colon syntax is the most natural thing to use, AND\n> script reading the output that used that syntax is forced to do\n> unnecessary work because \"git grep\" parrots the colon\n> literally, instread of being more intelligent about it\n> (i.e. omitting or substituting with slash when the input is a\n> tree object, not a tree-ish, as discussed in the thread).\n> \n> (2) where the colon syntax is the most natural thing, AND script\n> reading the output WANTS to see the distinction in the input\n> (remember, \"git grep\" can take more than one input tree).\n> \n> We haven't seen either of the above two in the discussion, so the\n> discussion so far is not sufficient to support the change being\n> proposed in this RFC, which requires that it is safe to assume that\n> (1) is the only case where the input is a raw tree (or the input\n> contains a colon) and (2) will never happen.\n> \n> So I am still mildly negative on the whole thing.\n\nAvoiding the colon syntax avoids the whole issue for my use case.\n\nI still think git-grep(1)'s output would be more useful if it used valid\ngit rev:path syntax in all cases.\n"},{"id":"310080","messageId":"20170123132918.GM29186@stefanha-x1.localdomain","threadId":"44915","inReplyTo":"xmqq60l9wdb9.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Stefan Hajnoczi","fromEmail":"stefanha@redhat.com","sentAt":"2017-01-23T13:29:18Z","receivedAt":"2017-01-24T09:54:05Z","isPatch":false,"sender":{"key":"stefanha@redhat.com","avatar":null},"body":"On Fri, Jan 20, 2017 at 02:56:26PM -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > It's not ignored; just as with git-log, it's a pathspec to limit the\n> > diff. E.g.:\n> >\n> > $ git show --name-status v2.9.3\n> > ...\n> > M Documentation/RelNotes/2.9.3.txt\n> > M Documentation/git.txt\n> > M GIT-VERSION-GEN\n> >\n> > $ git show --name-status v2.9.3 -- Documentation\n> > M Documentation/RelNotes/2.9.3.txt\n> > M Documentation/git.txt\n> >\n> > That's typically less useful than it is with log (where limiting the\n> > diff also kicks in history simplification and omits some commits\n> > entirely). But it does do something.\n> \n> I think Stefan is missing the fact that the argument to \"git show\n> :\" actually is naming a blob that sits at the \n> in the . In other words, \"show\" is acting as a glorified\n> \"git -p cat-file blob\", in that use.\n> \n> The use of \"git show\" you are demonstrating is still about showing\n> the commit object, whose behaviour is defined to show the log\n> message and the diff relative to its sole parent, limited to the\n> paths that match the pathspec.\n> \n> It is perfectly fine and desirable that \"git show :\"\n> and \"git show -- \" behaves differently. These are\n> two completely different features.\n\nThanks for explaining guys. It all makes logical sense. I just hope I\nremember the distinctions in that table for everyday git use.\n\nStefan\n"},{"id":"310097","messageId":"CABURp0qbvwSA1RcmCnVQVo-3O6rHZ3kP9dv0T9+mCzPWbAkHeQ@mail.gmail.com","threadId":"44915","inReplyTo":"20170123132918.GM29186@stefanha-x1.localdomain","subject":"Re: [RFC 2/2] grep: use '/' delimiter for paths","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2017-01-24T17:18:23Z","receivedAt":"2017-01-24T17:18:50Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Jan 24, 2017 at 1:54 AM Stefan Hajnoczi wrote:\n> > The use of \"git show\" you are demonstrating is still about showing\n> > the commit object, whose behaviour is defined to show the log\n> > message and the diff relative to its sole parent, limited to the\n> > paths that match the pathspec.\n> >\n> > It is perfectly fine and desirable that \"git show :\"\n> > and \"git show -- \" behaves differently. These are\n> > two completely different features.\n>\n> Thanks for explaining guys. It all makes logical sense. I just hope I\n> remember the distinctions in that table for everyday git use.\n\n\nFamiliar itch; previous discussion here:\n\nhttps://public-inbox.org/git/1377528372-31206-1-git-send-email-hordp@cisco.com/\n\nPhil\n"},{"id":"310104","messageId":"f90eba2a-ebfa-67f0-68c4-abacb05759ba@gmail.com","threadId":"44915","inReplyTo":"20170123131551.GL29186@stefanha-x1.localdomain","subject":"Re: [RFC 1/2] grep: only add delimiter if there isn't one already","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2017-01-24T19:07:48Z","receivedAt":"2017-01-24T19:08:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 23.01.2017 o 14:15, Stefan Hajnoczi pisze:\n> On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:\n\n>> My only piece of advice to folks who feel that way is to learn Git\n>> more and get comfortable. You can do neat things like\n>>\n>> $ git grep -e pattern rev -- t ':!t/helper/'\n>>\n>> that you cannot do with \"rev:t\", for example ;-)\n> \n> Neat, thanks for showing the path exclusion syntax. I wasn't aware of\n> it.\n\nThat reminds me of mu TODO item: moving extended pathspec information\nfrom gitglossary(7) manpage (sic!) to to-be-created gitpathspec(7).\n\n-- \nJakub Narębski\n\n"},{"id":"310111","messageId":"7611CDDCF2C34AFDB7995938228298B4@PhilipOakley","threadId":"44915","inReplyTo":"f90eba2a-ebfa-67f0-68c4-abacb05759ba@gmail.com","subject":"Re: [RFC 1/2] grep: only add delimiter if there isn't one already","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-24T20:50:55Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jakub Narębski\" \n>W dniu 23.01.2017 o 14:15, Stefan Hajnoczi pisze:\n>> On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:\n>\n>>> My only piece of advice to folks who feel that way is to learn Git\n>>> more and get comfortable. You can do neat things like\n>>>\n>>> $ git grep -e pattern rev -- t ':!t/helper/'\n>>>\n>>> that you cannot do with \"rev:t\", for example ;-)\n>>\n>> Neat, thanks for showing the path exclusion syntax. I wasn't aware of\n>> it.\n>\n> That reminds me of mu TODO item: moving extended pathspec information\n> from gitglossary(7) manpage (sic!) to to-be-created gitpathspec(7).\n>\n\nGood to see someone else also had it on a ToDo list..\n\nAttached is my collation of all the different path spec info I found from \ntrawling the man & guide pages to satisfy my ignorance...\n--\nPhilip \n\n\ngitpathspec(7)\n============\n\nNAME\n----\ngitpathspec - How to specify a path or file to git\n\nSYNOPSIS\n--------\n$HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore\n\nDESCRIPTION\n-----------\n\nPathspecs are used in a range of git functions.\n.gitignore\n.gitexclude\ngitsparse\ngit-add -- pathspec\ngit-checkout -- pathspec (after the double-dash)\ngit grep (active/non-active wild card matching)\ngit log (L#:<> pathspec limiters ?? what does it mean)\n\ngit rerere (uncontentious)\ngit status (uncontentious)\ngitk (uncontentious, but see 'log' above)\n'git' itself --\n--literal-pathspecs\nTreat pathspecs literally (i.e. no globbing, no pathspec magic). This is equivalent to setting the GIT_LITERAL_PATHSPECS environment variable to 1.\n\n--glob-pathspecs\nAdd \"glob\" magic to all pathspec. This is equivalent to setting the GIT_GLOB_PATHSPECS environment variable to 1. Disabling globbing on individual pathspecs can be done using pathspec magic \":(literal)\"\n\n--noglob-pathspecs\nAdd \"literal\" magic to all pathspec. This is equivalent to setting the GIT_NOGLOB_PATHSPECS environment variable to 1. Enabling globbing on individual pathspecs can be done using pathspec magic \":(glob)\"\n\n--icase-pathspecs\nAdd \"icase\" magic to all pathspec. This is equivalent to setting the GIT_ICASE_PATHSPECS environment variable to 1.\n\nsee glossary-content\npathspec\nPattern used to limit paths in Git commands.\n\nPathspecs are used on the command line of \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\", and many other commands to limit the scope of operations to some subset of the tree or worktree. See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows:\n\nany path matches itself\n\nthe pathspec up to the last slash represents a directory prefix. The scope of that pathspec is limited to that subtree.\n\nthe rest of the pathspec is a pattern for the remainder of the pathname. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, * and ? can match directory separators.\n\nFor example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg.\n\nA pathspec that begins with a colon : has special meaning. In the short form, the leading colon : is followed by zero or more \"magic signature\" letters (which optionally is terminated by another colon :), and the remainder is the pattern to match against the path. The \"magic signature\" consists of ASCII symbols that are neither alphanumeric, glob, regex special charaters nor colon. The optional colon that terminates the \"magic signature\" can be omitted if the pattern begins with a character that does not belong to \"magic signature\" symbol set and is not a colon.\n\nIn the long form, the leading colon : is followed by a open parenthesis (, a comma-separated list of zero or more \"magic words\", and a close parentheses ), and the remainder is the pattern to match against the path.\n\nA pathspec with only a colon means \"there is no pathspec\". This form should not be combined with other pathspec.\n\ntop\nThe magic word top (magic signature: /) makes the pattern match from the root of the working tree, even when you are running the command from inside a subdirectory.\n\nliteral\nWildcards in the pattern such as * or ? are treated as literal characters.\n\nicase\nCase insensitive match.\n\nglob\nGit treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, \"Documentation/*.html\" matches \"Documentation/git.html\" but not \"Documentation/ppc/ppc.html\" or \"tools/perf/Documentation/perf.html\".\n\nTwo consecutive asterisks (\"**\") in patterns matched against full pathname may have special meaning:\n\nA leading \"**\" followed by a slash means match in all directories. For example, \"**/foo\" matches file or directory \"foo\" anywhere, the same as pattern \"foo\". \"**/foo/bar\" matches file or directory \"bar\" anywhere that is directly under directory \"foo\".\n\nA trailing \"/**\" matches everything inside. For example, \"abc/**\" matches all files inside directory \"abc\", relative to the location of the .gitignore file, with infinite depth.\n\nA slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, \"a/**/b\" matches \"a/b\", \"a/x/b\", \"a/x/y/b\" and so on.\n\nOther consecutive asterisks are considered invalid.\n\nGlob magic is incompatible with literal magic.\n\nexclude\nAfter a path matches any non-exclude pathspec, it will be run through all exclude pathspec (magic signature: !). If it matches, the path is ignored.\n\nWhich characters to escape(\\) *:\\/ ??\n\nrooting (/*) of a path (a) $GIT_DIR (b) system root.\ndirectory (/) terminator (D/F conflict)\n\nCompare with ; ; and \n\n[glob(7) patterns] (see grep)\n\n` file specifies intentionally untracked files that\nGit should ignore.\nFiles already tracked by Git are not affected; see the NOTES\nbelow for details.\n\na `pathspec` is specified by a pattern.\nWhen deciding whether a path matches a `pathspec` pattern, Git normally checks\nwith the following\norder of precedence, from highest to lowest (within one level of\nprecedence, the last matching pattern decides the outcome):\n\n * Patterns read from the command line for those commands that support\n them.\n\n * Patterns read from a `.pathspec` 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 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 `.pathspec` file. A project normally includes such\n `.pathspec` files in its repository, containing patterns for\n files generated as part of the project build.\n\n * Patterns read from `$GIT_DIR/info/exclude`.\n\n * Patterns read from the file specified by the configuration\n variable 'core.excludesfile'.\n\nWhich file to place a pattern in depends on how the pattern is meant to\nbe used.\n\n * Patterns which should be version-controlled and distributed to\n other repositories via clone (i.e., files that all developers will want\n to ignore) should go into a `.pathspec` file.\n\n * Patterns which are\n specific to a particular repository but which do not need to be shared\n with other related repositories (e.g., auxiliary files that live inside\n the repository but are specific to one user's workflow) should go into\n the `$GIT_DIR/info/exclude` file.\n\n * Patterns which a user wants Git to\n ignore in all situations (e.g., backup or temporary files generated by\n the user's editor of choice) generally go into a file specified by\n `core.excludesfile` in the user's `~/.gitconfig`. Its default value is\n $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or\n empty, $HOME/.config/git/ignore is used instead.\n\nThe underlying Git plumbing tools, such as\n'git ls-files' and 'git read-tree', read\n`pathspec` patterns specified by command-line options, or from\nfiles specified by command-line options. Higher-level Git\ntools, such as 'git status' and 'git add',\nuse patterns from the sources specified above.\n\nPATTERN FORMAT\n--------------\n\n - A blank line matches no files, so it can serve as a separator\n for readability.\n\n - A line starting with # serves as a comment.\n Put a backslash (\"`\\`\") in front of the first hash for patterns\n that begin with a hash.\n\n - An optional prefix \"`!`\" which negates the pattern; any\n matching file excluded by a previous pattern will become\n included again. It is not possible to re-include a file if a parent\n directory of that file is excluded. Git doesn't list excluded\n directories for performance reasons, so any patterns on contained\n files have no effect, no matter where they are defined.\n Put a backslash (\"`\\`\") in front of the first \"`!`\" for patterns\n that begin with a literal \"`!`\", for example, \"`\\!important!.txt`\".\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 a match with a directory. In other words, `foo/` will match a\n directory `foo` and paths underneath it, but will not match a\n regular file or a symbolic link `foo` (this is consistent\n with the way how pathspec works in general in Git).\n\n - If the pattern does not contain a slash '/', Git treats it as\n a shell glob pattern and checks for a match against the\n pathname relative to the location of the `.pathspec` file\n (relative to the toplevel of the work tree if not from a\n `.pathspec` file).\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 For example, \"Documentation/{asterisk}.html\" matches\n \"Documentation/git.html\" but not \"Documentation/ppc/ppc.html\"\n or \"tools/perf/Documentation/perf.html\".\n\n - A leading slash matches the beginning of the pathname.\n For example, \"/{asterisk}.c\" matches \"cat-file.c\" but not\n \"mozilla-sha1/sha1.c\".\n\nTwo consecutive asterisks (\"`**`\") in patterns matched against\nfull pathname may have special meaning:\n\n - A leading \"`**`\" followed by a slash means match in all\n directories. For example, \"`**/foo`\" matches file or directory\n \"`foo`\" anywhere, the same as pattern \"`foo`\". \"`**/foo/bar`\"\n matches file or directory \"`bar`\" anywhere that is directly\n under directory \"`foo`\".\n\n - A trailing \"`/**`\" matches everything inside. For example,\n \"`abc/**`\" matches all files inside directory \"`abc`\", relative\n to the location of the `.pathspec` file, with infinite depth.\n\n - A slash followed by two consecutive asterisks then a slash\n matches zero or more directories. For example, \"`a/**/b`\"\n matches \"`a/b`\", \"`a/x/b`\", \"`a/x/y/b`\" and so on.\n\n - Other consecutive asterisks are considered invalid.\n\nNOTES\n-----\n\nThe purpose of pathspec files is to ensure that certain files\nnot tracked by Git remain untracked.\n\nTo ignore uncommitted changes in a file that is already tracked,\nuse 'git update-index {litdd}assume-unchanged'.\n\nTo stop tracking a file that is currently tracked, use\n'git rm --cached'.\n\nEXAMPLES\n--------\n\n--------------------------------------------------------------\n $ git status\n [...]\n # Untracked files:\n [...]\n # Documentation/foo.html\n # Documentation/pathspec.html\n # file.o\n # lib.a\n # src/internal.o\n [...]\n $ cat .git/info/exclude\n # ignore objects and archives, anywhere in the tree.\n *.[oa]\n $ cat Documentation/.pathspec\n # ignore generated html files,\n *.html\n # except foo.html which is maintained by hand\n !foo.html\n $ git status\n [...]\n # Untracked files:\n [...]\n # Documentation/foo.html\n [...]\n--------------------------------------------------------------\n\nAnother example:\n\n--------------------------------------------------------------\n $ cat .pathspec\n vmlinux*\n $ ls arch/foo/kernel/vm*\n arch/foo/kernel/vmlinux.lds.S\n $ echo '!/vmlinux*' >arch/foo/kernel/.pathspec\n--------------------------------------------------------------\n\nThe second .pathspec prevents Git from ignoring\n`arch/foo/kernel/vmlinux.lds.S`.\n\nExample to exclude everything except a specific directory `foo/bar`\n(note the `/*` - without the slash, the wildcard would also exclude\neverything within `foo/bar`):\n\n--------------------------------------------------------------\n $ cat .pathspec\n # exclude everything except directory foo/bar\n /*\n !/foo\n /foo/*\n !/foo/bar\n--------------------------------------------------------------\n\nSEE ALSO\n--------\nlinkgit:git-rm[1],\nlinkgit:git-update-index[1],\nlinkgit:gitrepository-layout[5],\nlinkgit:git-check-ignore[1]\n\nGIT\n---\nPart of the linkgit:git[1] suite\n"}]}