{"thread":{"id":"34762","subject":"[RFC/PATCH] Fix path prefixing in grep_object","startedAt":"2013-08-25T01:35:58Z","lastAt":"2013-08-27T11:54:34Z","messageCount":19,"participants":["Phil Hord","Junio C Hamano","Jonathan Nieder","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"225800","messageId":"1377394558-371-1-git-send-email-hordp@cisco.com","threadId":"34762","inReplyTo":null,"subject":"[RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2013-08-25T01:35:58Z","receivedAt":"2013-08-25T01:35:58Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"When the pathspec given to grep includes a tree name, the full\nname of matched files is assembled using colon as a separator.\nIf the pathspec includes a tree name, it should use a slash\ninstead.\n\nCheck if the pathspec already names a tree and ref (including\na colon) and use a slash if so.\n---\n\nI'm not sure about the detection I used here.  It works, but it is\nnot terribly robust.  Is there a better way to handle this?  Maybe\nsomething like 'prefix_pathspec(name,\"\");'.\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 03bc442..d0deae4 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -480,8 +480,9 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n \t\tlen = name ? strlen(name) : 0;\n \t\tstrbuf_init(&base, PATH_MAX + len + 1);\n \t\tif (len) {\n+\t\t\tint has_colon = !!strchr(name,':');\n \t\t\tstrbuf_add(&base, name, len);\n-\t\t\tstrbuf_addch(&base, ':');\n+\t\t\tstrbuf_addch(&base, has_colon?'/':':');\n \t\t}\n \t\tinit_tree_desc(&tree, data, size);\n \t\thit = grep_tree(opt, pathspec, &tree, &base, base.len,\n-- \n1.8.4.557.g34b3a2e\n"},{"id":"225801","messageId":"CABURp0qG7Nnjpp17MAO7Ltwf51EsswZ3GcT-qyt14Vs1tc9pGw@mail.gmail.com","threadId":"34762","inReplyTo":"1377394558-371-1-git-send-email-hordp@cisco.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-08-25T02:07:30Z","receivedAt":"2013-08-25T02:07:30Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord <hordp@cisco.com> wrote:\n>\n> When the pathspec given to grep includes a tree name, the full\n> name of matched files is assembled using colon as a separator.\n> If the pathspec includes a tree name, it should use a slash\n> instead.\n>\n> Check if the pathspec already names a tree and ref (including\n> a colon) and use a slash if so.\n\nI think I used lots of wrong terminology there.  What do I call these\nthings?\n\nHEAD:path is a tree.\n\nHEAD is a commit name.\n\nMaybe like this?\n\n  When a tree is given to grep, the full name of matched files\n  is assembled using colon as a separator.\n\n  If the tree name includes an object name, as in\n  HEAD:some/path, it should use a slash instead.\n\nPhil\n"},{"id":"225811","messageId":"xmqqa9k6moif.fsf@gitster.dls.corp.google.com","threadId":"34762","inReplyTo":"CABURp0qG7Nnjpp17MAO7Ltwf51EsswZ3GcT-qyt14Vs1tc9pGw@mail.gmail.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-25T03:35:04Z","receivedAt":"2013-08-25T03:35:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord <phil.hord@gmail.com> writes:\n\n> On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord <hordp@cisco.com> wrote:\n>>\n>> When the pathspec given to grep includes a tree name, the full\n>> name of matched files is assembled using colon as a separator.\n>> If the pathspec includes a tree name, it should use a slash\n>> instead.\n>>\n>> Check if the pathspec already names a tree and ref (including\n>> a colon) and use a slash if so.\n>\n> I think I used lots of wrong terminology there.  What do I call these\n> things?\n>\n> HEAD:path is a tree.\n\nIt is one way to name a tree object, yes (another obvious way is to\nspell it out, e.g. 3610ac62).\n\n> HEAD is a commit name.\n\nIt is one way to name the commit object, yes, but I am guessing that\nyou are interested in these in the context of resolving HEAD:path.\nIf that is the case, then \"commit\"-ness is not something you are\ninterested in---any tree-ish would do (e.g. v1.8.4, maint^{tree}).\n\n> Maybe like this?\n>\n>   When a tree is given to grep, the full name of matched files\n>   is assembled using colon as a separator.\n>\n>   If the tree name includes an object name, as in\n>   HEAD:some/path, it should use a slash instead.\n\nWhat problem are you trying to solve?  It should use HEAD:some/path,\nnot HEAD/some/path.\n"},{"id":"225820","messageId":"20130825042314.GE2882@elie.Belkin","threadId":"34762","inReplyTo":"xmqqa9k6moif.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-08-25T04:23:14Z","receivedAt":"2013-08-25T04:23:14Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Phil Hord <phil.hord@gmail.com> writes:\n>> On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord <hordp@cisco.com> wrote:\n\n>>> When the pathspec given to grep includes a tree name, the full\n>>> name of matched files is assembled using colon as a separator.\n>>> If the pathspec includes a tree name, it should use a slash\n>>> instead.\n[...]\n>>   If the tree name includes an object name, as in\n>>   HEAD:some/path, it should use a slash instead.\n>\n> What problem are you trying to solve?  It should use HEAD:some/path,\n> not HEAD/some/path.\n\nI think Phil meant that when \"git grep\" is asked to search within\n\"HEAD:some/path\", filenames tacked on at the end should be appended\nwith a '/' separator instead of the usual ':' (e.g.,\n\"HEAD:some/path/inner/path.c\", not \"HEAD:some/path:inner/path.c\").\nOtherwise I cannot copy and paste \"git grep\" output and get something\nsuitable for passing to \"git show\".\n\nI don't think we have a standard name for the tree:path syntax.  I've\nalways just called it tree:path syntax. :)\n\nHope that helps,\nJonathan\n"},{"id":"225822","messageId":"20130825044108.GA21300@sigill.intra.peff.net","threadId":"34762","inReplyTo":"1377394558-371-1-git-send-email-hordp@cisco.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-25T04:41:09Z","receivedAt":"2013-08-25T04:41:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 24, 2013 at 09:35:58PM -0400, Phil Hord wrote:\n\n> When the pathspec given to grep includes a tree name, the full\n> name of matched files is assembled using colon as a separator.\n> If the pathspec includes a tree name, it should use a slash\n> instead.\n> \n> Check if the pathspec already names a tree and ref (including\n> a colon) and use a slash if so.\n\nMakes sense.\n\n> I'm not sure about the detection I used here.  It works, but it is\n> not terribly robust.  Is there a better way to handle this?  Maybe\n> something like 'prefix_pathspec(name,\"\");'.\n\nI think the information you want has been thrown away by the time we get\nto grep_object. Only get_sha1 knows whether the name was really a direct\ntree reference or if it had to traverse paths.\n\nSo we are necessarily reconstructing based on what we know of the\nsyntax. And I think that your rule is OK, because we know that refnames\ncannot contain a colon. So even though pathnames can, we do not have to\ncare; we only want to know \"is there a path in the name\", and if we have\nat least one colon, the answer is yes.\n\n>  builtin/grep.c | 3 ++-\n>  1 file changed, 2 insertions(+), 1 deletion(-)\n\nA test would be nice. Both to make sure we do not re-break it, and because\nit helps demonstrate the problem very easily (it took me a minute to\nfigure out what was going on from your description).\n\n> diff --git a/builtin/grep.c b/builtin/grep.c\n> index 03bc442..d0deae4 100644\n> --- a/builtin/grep.c\n> +++ b/builtin/grep.c\n> @@ -480,8 +480,9 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,\n>  \t\tlen = name ? strlen(name) : 0;\n>  \t\tstrbuf_init(&base, PATH_MAX + len + 1);\n>  \t\tif (len) {\n> +\t\t\tint has_colon = !!strchr(name,':');\n>  \t\t\tstrbuf_add(&base, name, len);\n> -\t\t\tstrbuf_addch(&base, ':');\n> +\t\t\tstrbuf_addch(&base, has_colon?'/':':');\n\nPlease use whitespace with your ternary operator. The '/':':' made me\nthink I was reading Perl for a minute. :)\n\n-Peff\n"},{"id":"225829","messageId":"xmqqk3jal4t7.fsf@gitster.dls.corp.google.com","threadId":"34762","inReplyTo":"20130825042314.GE2882@elie.Belkin","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-25T05:25:56Z","receivedAt":"2013-08-25T05:25:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> I think Phil meant that when \"git grep\" is asked to search within\n> \"HEAD:some/path\", filenames tacked on at the end should be appended\n> with a '/' separator instead of the usual ':' (e.g.,\n> \"HEAD:some/path/inner/path.c\", not \"HEAD:some/path:inner/path.c\").\n\nAh, OK.\n\nI am not sure if we have a proper hint in the revision parser\nmachinery, but it may not be too hard to teach rev-cmdline interface\nto keep that kind of information (i.e. \"This tree object name is a\nresult of parsing '<tree-ish>:path' syntax\").\n"},{"id":"225831","messageId":"20130825054142.GM2882@elie.Belkin","threadId":"34762","inReplyTo":"20130825044108.GA21300@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-08-25T05:41:42Z","receivedAt":"2013-08-25T05:41:42Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> So we are necessarily reconstructing based on what we know of the\n> syntax. And I think that your rule is OK, because we know that refnames\n> cannot contain a colon.\n\nWhat happens with expressions like HEAD^{/test:}?\n\nJonathan\n"},{"id":"225832","messageId":"20130825055433.GA7296@sigill.intra.peff.net","threadId":"34762","inReplyTo":"20130825054142.GM2882@elie.Belkin","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-25T05:54:33Z","receivedAt":"2013-08-25T05:54:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 24, 2013 at 10:41:42PM -0700, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> \n> > So we are necessarily reconstructing based on what we know of the\n> > syntax. And I think that your rule is OK, because we know that refnames\n> > cannot contain a colon.\n> \n> What happens with expressions like HEAD^{/test:}?\n\nUgh, right. Names are more than just refnames.\n\nSo I think the only way to do this robustly is to ask get_sha1 to\nremember more about what happened. We might even be able to get away\nwithout teaching get_sha1_with_context anything else; it already records\nthe path, so we should be able to just check whether that is non-empty.\n\nBut we use an object_array to store the list of objects, and it has no\nroom for such a bit. So we'd probably want to refactor that, too.\n\n-Peff\n"},{"id":"225886","messageId":"xmqqfvtwkjp8.fsf@gitster.dls.corp.google.com","threadId":"34762","inReplyTo":"xmqqk3jal4t7.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-26T07:14:11Z","receivedAt":"2013-08-26T07:14:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> I think Phil meant that when \"git grep\" is asked to search within\n>> \"HEAD:some/path\", filenames tacked on at the end should be appended\n>> with a '/' separator instead of the usual ':' (e.g.,\n>> \"HEAD:some/path/inner/path.c\", not \"HEAD:some/path:inner/path.c\").\n>\n> Ah, OK.\n>\n> I am not sure if we have a proper hint in the revision parser\n> machinery, but it may not be too hard to teach rev-cmdline interface\n> to keep that kind of information (i.e. \"This tree object name is a\n> result of parsing '<tree-ish>:path' syntax\").\n\nActually, having thought about this a bit more, I am no longer sure\nif this is even a good idea to begin with.\n\nAn output line that begins with HEAD:some/path:inner/path.c from\n\"git grep\" is an answer to this question: find the given pattern in\na tree-ish specified with \"HEAD:some/path\".\n\nOn the other hand, HEAD:some/path/inner/path.c is an answer to a\ndifferent question: find the pattern in a tree-ish specified with\n\"HEAD\".  The question may optionally be further qualified with \"but\nlimit the search to some/path\".  Both the question and its answer\nare more intuitive than the former one.\n\nAnd we have a nice way to ask that question directly, i.e.\n\n    $ git grep -e pattern HEAD some/path\n\nwhich can be extended naturally to more than one path, e.g.\n\n    $ git grep -e pattern HEAD some/path another/hierarchy\n\nwithout having to repeat HEAD: part again for each path.\n\nIf the user asked the question of the former form, i.e.\n\n    $ git grep -e pattern HEAD:some/path\n\nthere may be a reason why the user wanted to ask it in that\n(somewhat strange) way.  I am not 100% sure if it is a good idea to\ngive an answer to a question different from what the user asked by\ninternally rewriting the question to\n\n    $ git grep -e pattern HEAD -- some/path\n\nSo...\n"},{"id":"225896","messageId":"CABURp0oGMTEgX3TKKEMAOxe6T0=uij+bAyc+5u0x_UHwEPo3CQ@mail.gmail.com","threadId":"34762","inReplyTo":"xmqqfvtwkjp8.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-08-26T11:44:09Z","receivedAt":"2013-08-26T11:44:09Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Jonathan Nieder <jrnieder@gmail.com> writes:\n>>\n>>> I think Phil meant that when \"git grep\" is asked to search within\n>>> \"HEAD:some/path\", filenames tacked on at the end should be appended\n>>> with a '/' separator instead of the usual ':' (e.g.,\n>>> \"HEAD:some/path/inner/path.c\", not \"HEAD:some/path:inner/path.c\").\n>>\n>> Ah, OK.\n>>\n>> I am not sure if we have a proper hint in the revision parser\n>> machinery, but it may not be too hard to teach rev-cmdline interface\n>> to keep that kind of information (i.e. \"This tree object name is a\n>> result of parsing '<tree-ish>:path' syntax\").\n>\n> Actually, having thought about this a bit more, I am no longer sure\n> if this is even a good idea to begin with.\n>\n> An output line that begins with HEAD:some/path:inner/path.c from\n> \"git grep\" is an answer to this question: find the given pattern in\n> a tree-ish specified with \"HEAD:some/path\".\n>\n> On the other hand, HEAD:some/path/inner/path.c is an answer to a\n> different question: find the pattern in a tree-ish specified with\n> \"HEAD\".  The question may optionally be further qualified with \"but\n> limit the search to some/path\".  Both the question and its answer\n> are more intuitive than the former one.\n\nI disagree.  The man page says that git grep lists the filenames of\nmatching files.  And it usually does.  When told to search in a\ndifferent branch, the filename is helpfully shown in a form that other\ngit commands recognize, namely $branch:$path. This is useful for\nscripts that want to do something with the resulting file names.\n\nBut when a path included in the query with the branch, the output is\nuseless to my scripts or finger memory without some cleanup first.\nThe aim of this patch is to fix that so the cleanup is not necessary.\n\n   $ git grep -l setup_check HEAD Documentation\n   HEAD:Documentation/technical/api-gitattributes.txt\n\n   $ git grep -l setup_check HEAD:Documentation\n   HEAD:Documentation:technical/api-gitattributes.txt\n\nThe path in the first example is meaningful.  The path in the second\nexample is erroneous.\n\n\n> And we have a nice way to ask that question directly, i.e.\n>\n>     $ git grep -e pattern HEAD some/path\n>\n> which can be extended naturally to more than one path, e.g.\n>\n>     $ git grep -e pattern HEAD some/path another/hierarchy\n>\n> without having to repeat HEAD: part again for each path.\n\nYes, but that's not always what I want. Sometimes I want to search on\ndifferent trees. When doing so, why should I be crippled with broken\noutput?\n\n    $ git grep -e pattern origin/master:some/path origin/next:another/hierarchy\n    origin/master:some/path:sub/dir/foo.txt\n    origin/next:another/hierarchy:path/frotz.c\n\nI would prefer to have real paths I can pass to 'git show', ones with\njust one meaningful colon rather than two vague ones:\n\n    origin/master:some/path/sub/dir/foo.txt\n    origin/next:another/hierarchy/path/frotz.c\n\n> If the user asked the question of the former form, i.e.\n>\n>     $ git grep -e pattern HEAD:some/path\n>\n> there may be a reason why the user wanted to ask it in that\n> (somewhat strange) way.  I am not 100% sure if it is a good idea to\n> give an answer to a question different from what the user asked by\n> internally rewriting the question to\n>\n>     $ git grep -e pattern HEAD -- some/path\n\nWe are not rewriting the question at all.\n\nThe current code assumes the user gave only an object name and is\ntrying to help by prefixing that name on the matched path using the\ncolon as a separator, as would be the norm.  But that is the wrong\nseparator in some cases, specifically when the tree reference includes\na path.\n\nPhil\n"},{"id":"225905","messageId":"xmqqr4dgifp5.fsf@gitster.dls.corp.google.com","threadId":"34762","inReplyTo":"CABURp0oGMTEgX3TKKEMAOxe6T0=uij+bAyc+5u0x_UHwEPo3CQ@mail.gmail.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-26T16:23:34Z","receivedAt":"2013-08-26T16:23:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord <phil.hord@gmail.com> writes:\n\n> On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> Jonathan Nieder <jrnieder@gmail.com> writes:\n>>>\n>>>> I think Phil meant that when \"git grep\" is asked to search within\n>>>> \"HEAD:some/path\", filenames tacked on at the end should be appended\n>>>> with a '/' separator instead of the usual ':' (e.g.,\n>>>> \"HEAD:some/path/inner/path.c\", not \"HEAD:some/path:inner/path.c\").\n>>>\n>>> Ah, OK.\n>>>\n>>> I am not sure if we have a proper hint in the revision parser\n>>> machinery, but it may not be too hard to teach rev-cmdline interface\n>>> to keep that kind of information (i.e. \"This tree object name is a\n>>> result of parsing '<tree-ish>:path' syntax\").\n>>\n>> Actually, having thought about this a bit more, I am no longer sure\n>> if this is even a good idea to begin with.\n>>\n>> An output line that begins with HEAD:some/path:inner/path.c from\n>> \"git grep\" is an answer to this question: find the given pattern in\n>> a tree-ish specified with \"HEAD:some/path\".\n>>\n>> On the other hand, HEAD:some/path/inner/path.c is an answer to a\n>> different question: find the pattern in a tree-ish specified with\n>> \"HEAD\".  The question may optionally be further qualified with \"but\n>> limit the search to some/path\".  Both the question and its answer\n>> are more intuitive than the former one.\n>\n> I disagree.  The man page says that git grep lists the filenames of\n> matching files.\n\nBut you need to realize that the manual page gives a white lie in\norder to stay short enough to be readable.  It does give filenames\nwhen reading from the working tree, the index or a top-level tree\nobject.  When given arbitrary tree object that is not top-level, it\ndoes give filenames relative to the given tree object, which is the\nanswer HEAD:some/path:inner/path.c to the question \"where in the\ntree HEAD:some/path do we have hits?\".\n\n>> If the user asked the question of the former form, i.e.\n>>\n>>     $ git grep -e pattern HEAD:some/path\n>>\n>> there may be a reason why the user wanted to ask it in that\n>> (somewhat strange) way.  I am not 100% sure if it is a good idea to\n>> give an answer to a question different from what the user asked by\n>> internally rewriting the question to\n>>\n>>     $ git grep -e pattern HEAD -- some/path\n>\n> We are not rewriting the question at all.\n\nThat statement is trapped in a narrow \"implementor\" mind. I know you\nare not rewriting the question in your implementation, but what do\nthe end users see? It gives an answer to a question different from\nthey asked; the observed behaviour is as if the question was\nrewritten before the machinery went to work.\n\nIf your justification were \"above says 'there may be a readon why\nthe user wanted to ask it in that way', i.e. 'find in this tree\nobject HEAD:some/path and report where hits appear', but the reason\ncan only be from laziness and/or broken script and the user always\nwants the answer from within the top-level tree-ish\", then that\nargument may make some sense. You need to justify why it is OK to\nlose information in the answer by rewriting the colon that separates\nthe question (\"in this tree object\") and the answer (\"at this path\nrelative to the tree object given\").\n\nWhether you rewrite the input or the output is not important; you\nare trying to give an answer to a different question, which is what\nI find questionable.\n"},{"id":"225908","messageId":"CABURp0odEGgZO1yWFgXS+akPb4wJHiTLoQcmqBd00oYnPZ77vA@mail.gmail.com","threadId":"34762","inReplyTo":"xmqqr4dgifp5.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-08-26T16:49:15Z","receivedAt":"2013-08-26T16:49:15Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Aug 26, 2013 at 12:23 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Phil Hord <phil.hord@gmail.com> writes:\n>\n>> On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Junio C Hamano <gitster@pobox.com> writes:\n>>>\n>>>> Jonathan Nieder <jrnieder@gmail.com> writes:\n>>>>\n>>>>> I think Phil meant that when \"git grep\" is asked to search within\n>>>>> \"HEAD:some/path\", filenames tacked on at the end should be appended\n>>>>> with a '/' separator instead of the usual ':' (e.g.,\n>>>>> \"HEAD:some/path/inner/path.c\", not \"HEAD:some/path:inner/path.c\").\n>>>>\n>>>> Ah, OK.\n>>>>\n>>>> I am not sure if we have a proper hint in the revision parser\n>>>> machinery, but it may not be too hard to teach rev-cmdline interface\n>>>> to keep that kind of information (i.e. \"This tree object name is a\n>>>> result of parsing '<tree-ish>:path' syntax\").\n>>>\n>>> Actually, having thought about this a bit more, I am no longer sure\n>>> if this is even a good idea to begin with.\n>>>\n>>> An output line that begins with HEAD:some/path:inner/path.c from\n>>> \"git grep\" is an answer to this question: find the given pattern in\n>>> a tree-ish specified with \"HEAD:some/path\".\n>>>\n>>> On the other hand, HEAD:some/path/inner/path.c is an answer to a\n>>> different question: find the pattern in a tree-ish specified with\n>>> \"HEAD\".  The question may optionally be further qualified with \"but\n>>> limit the search to some/path\".  Both the question and its answer\n>>> are more intuitive than the former one.\n>>\n>> I disagree.  The man page says that git grep lists the filenames of\n>> matching files.\n>\n> But you need to realize that the manual page gives a white lie in\n> order to stay short enough to be readable.  It does give filenames\n> when reading from the working tree, the index or a top-level tree\n> object.  When given arbitrary tree object that is not top-level, it\n> does give filenames relative to the given tree object, which is the\n> answer HEAD:some/path:inner/path.c to the question \"where in the\n> tree HEAD:some/path do we have hits?\".\n>\n>>> If the user asked the question of the former form, i.e.\n>>>\n>>>     $ git grep -e pattern HEAD:some/path\n>>>\n>>> there may be a reason why the user wanted to ask it in that\n>>> (somewhat strange) way.  I am not 100% sure if it is a good idea to\n>>> give an answer to a question different from what the user asked by\n>>> internally rewriting the question to\n>>>\n>>>     $ git grep -e pattern HEAD -- some/path\n>>\n>> We are not rewriting the question at all.\n>\n> That statement is trapped in a narrow \"implementor\" mind. I know you\n> are not rewriting the question in your implementation, but what do\n> the end users see? It gives an answer to a question different from\n> they asked; the observed behaviour is as if the question was\n> rewritten before the machinery went to work.\n>\n> If your justification were \"above says 'there may be a readon why\n> the user wanted to ask it in that way', i.e. 'find in this tree\n> object HEAD:some/path and report where hits appear', but the reason\n> can only be from laziness and/or broken script and the user always\n> wants the answer from within the top-level tree-ish\", then that\n> argument may make some sense. You need to justify why it is OK to\n> lose information in the answer by rewriting the colon that separates\n> the question (\"in this tree object\") and the answer (\"at this path\n> relative to the tree object given\").\n>\n> Whether you rewrite the input or the output is not important; you\n> are trying to give an answer to a different question, which is what\n> I find questionable.\n\nOk, so if I can summarize what I am inferring from your objection:\n\n 1. The (tree-path, found-path) pair is useful information to get back\nfrom git-grep.\n\n 2. A colon is used to delimit these pieces of information, just as a\ncolon is used to delimit the filename from the matched-line results.\n\n 3. The fact that the colon is also the separator used in object refs\nis mere coincidence; the colon was _not_ chosen because it\nconveniently turns the results list into valid object references.  A\ncomma could have been instead, or even a \\t.\n\nHave I got that right?\n\nIf so, then I would like to point out to you the convenience I\naccidentally encountered using this tool.  Perhaps you didn't realize\nhow helpful it was when you chose to use a colon there.\n\nOn the other hand, perhaps a colon is an unfortunate syntactic\ncollision which should be corrected in the future.\n\nPhil\n"},{"id":"225910","messageId":"xmqqioysidu1.fsf@gitster.dls.corp.google.com","threadId":"34762","inReplyTo":"xmqqr4dgifp5.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-26T17:03:50Z","receivedAt":"2013-08-26T17:03:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> If your justification were \"above says 'there may be a readon why\n> the user wanted to ask it in that way', i.e. 'find in this tree\n> object HEAD:some/path and report where hits appear', but the reason\n> can only be from laziness and/or broken script and the user always\n> wants the answer from within the top-level tree-ish\", then that\n> argument may make some sense. You need to justify why it is OK to\n> lose information in the answer by rewriting the colon that separates\n> the question (\"in this tree object\") and the answer (\"at this path\n> relative to the tree object given\").\n>\n> Whether you rewrite the input or the output is not important; you\n> are trying to give an answer to a different question, which is what\n> I find questionable.\n\nFor example, one of the cases the proposed change will break that I\nam worried about is a script that wants to take N trees and a\npattern, and report where in the given trees hits appear, something\nlike:\n\ngit grep -c -e $pattern \"$@\" |\nperl -e '\n\tmy @trees = @ARGV;\n\tmy %found = ();\n\twhile (<>) {\n\t        my $line = $_;\n\t        for (@trees) {\n\t\t\tmy $tree_prefix = $_ . \":\";\n\t\t\tmy $len = len($tree_prefix);\n\t\t\tif (substr($line, 0, $len) eq $tree_prefix) {\n\t\t\t\tmy ($path_count) = substr($line, $len);\n\t\t\t\tmy ($path, $count) = $path_count =~ /^(.*):(\\d+)$/\n\t\t\t\t$found{$tree} = [$path, $count];\n\t\t\t}\n\t\t}\n\t}\n\t# Do stats on %found\n' \"$@\"\n"},{"id":"225911","messageId":"CABURp0okEN7cHF2ZWmk-8jf0QFmJN3p-P2bHvF2BH=ws7ne7wA@mail.gmail.com","threadId":"34762","inReplyTo":"CABURp0odEGgZO1yWFgXS+akPb4wJHiTLoQcmqBd00oYnPZ77vA@mail.gmail.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-08-26T17:07:43Z","receivedAt":"2013-08-26T17:07:43Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Aug 26, 2013 at 12:49 PM, Phil Hord <phil.hord@gmail.com> wrote:\n> If so, then I would like to point out to you the convenience I\n> accidentally encountered using this tool.  Perhaps you didn't realize\n> how helpful it was when you chose to use a colon there.\n\nMy itch comes from a case where I am looking for references in some\nother branch and I want to narrow my search.\n\n  $ git grep object origin/master\n  origin/master:.gitignore:/git-count-objects\n  origin/master:.gitignore:/git-fsck-objects\n  origin/master:.gitignore:/git-hash-object\n  <8600 lines more deleted>\n\nI find hits in the region that interests me and then I try to zoom in\nthere.  Conveniently, the path I want to search is right there on my\nscreen.  So I copy the part of the object reference I want to limit my\nsearch to, and I try again:\n\n   $ git grep object origin/master:builtin/\n\nNow, I find the file that has the code I wanted.  But I want to do\nsomething fancier to it than grep, so this time I copy-and-paste the\nfilename into my command line after typing 'git show':\n\n   $ git show origin/master:builtin/pack-objects.c | vim -\n\nBut this doesn't work if the delimiter used was a colon.\n\n   $ git show origin/master:builtin:pack-objects.c | vim -\n\nI have to edit my copy-and-pasted text, which means I have think about\nit a bit, and it interrupts all the other things I was thinking about\nalready.  Eventually I might learn to do this edit automatically,\nexcept it is not needed most of the time.  It is only needed when I\nprovide a tree-path instead of a \"branch <space> path\". In the latter\ncase, the full path is spelled out for me correctly.  And in all other\ncases the filenames provided by git-grep are valid filenames or object\nnames.\n"},{"id":"225913","messageId":"CABURp0oTsyG-FCgAzYZjtwwP_VMudV0=_Z5eOe+qbhPbmPqx4g@mail.gmail.com","threadId":"34762","inReplyTo":"xmqqioysidu1.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-08-26T17:19:50Z","receivedAt":"2013-08-26T17:19:50Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Aug 26, 2013 at 1:03 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> If your justification were \"above says 'there may be a readon why\n>> the user wanted to ask it in that way', i.e. 'find in this tree\n>> object HEAD:some/path and report where hits appear', but the reason\n>> can only be from laziness and/or broken script and the user always\n>> wants the answer from within the top-level tree-ish\", then that\n>> argument may make some sense. You need to justify why it is OK to\n>> lose information in the answer by rewriting the colon that separates\n>> the question (\"in this tree object\") and the answer (\"at this path\n>> relative to the tree object given\").\n>>\n>> Whether you rewrite the input or the output is not important; you\n>> are trying to give an answer to a different question, which is what\n>> I find questionable.\n>\n> For example, one of the cases the proposed change will break that I\n> am worried about is a script that wants to take N trees and a\n> pattern, and report where in the given trees hits appear, something\n> like:\n>\n> git grep -c -e $pattern \"$@\" |\n> perl -e '\n>         my @trees = @ARGV;\n>         my %found = ();\n>         while (<>) {\n>                 my $line = $_;\n>                 for (@trees) {\n>                         my $tree_prefix = $_ . \":\";\n>                         my $len = len($tree_prefix);\n>                         if (substr($line, 0, $len) eq $tree_prefix) {\n>                                 my ($path_count) = substr($line, $len);\n>                                 my ($path, $count) = $path_count =~ /^(.*):(\\d+)$/\n>                                 $found{$tree} = [$path, $count];\n>                         }\n>                 }\n>         }\n>         # Do stats on %found\n> ' \"$@\"\n>\n\nI do understand there is potential breakage when a script is parsing\nthe output.  I did not consider that this was a feature someone may\nwant; it really only looks like a breakage to me, for the reasons I've\nalready given.\n\nIt's surprising just how broken it looks to me (given that I now know\nit is not) since all the other filenames output from 'git-grep -l' are\nvalid filenames or object references.  There is only this one\ntree-path instance which does not.  I suppose I will learn to live\nwith it.\n"},{"id":"225914","messageId":"xmqqbo4kicsm.fsf@gitster.dls.corp.google.com","threadId":"34762","inReplyTo":"CABURp0odEGgZO1yWFgXS+akPb4wJHiTLoQcmqBd00oYnPZ77vA@mail.gmail.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-26T17:26:17Z","receivedAt":"2013-08-26T17:26:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord <phil.hord@gmail.com> writes:\n\n>> If your justification were \"above says 'there may be a readon why\n>> the user wanted to ask it in that way', i.e. 'find in this tree\n>> object HEAD:some/path and report where hits appear', but the reason\n>> can only be from laziness and/or broken script and the user always\n>> wants the answer from within the top-level tree-ish\", then that\n>> argument may make some sense. You need to justify why it is OK to\n>> lose information in the answer by rewriting the colon that separates\n>> the question (\"in this tree object\") and the answer (\"at this path\n>> relative to the tree object given\").\n>>\n>> Whether you rewrite the input or the output is not important; you\n>> are trying to give an answer to a different question, which is what\n>> I find questionable.\n>\n> Ok, so if I can summarize what I am inferring from your objection:\n>\n>  1. The (tree-path, found-path) pair is useful information to get back\n> from git-grep.\n\nAt least that was the intent. I can be persuaded that your change\nwill not break anybody if you successfully argue that it is not a\nuseful information, though.\n\n>  2. A colon is used to delimit these pieces of information, just as a\n> colon is used to delimit the filename from the matched-line results.\n>\n>  3. The fact that the colon is also the separator used in object refs\n> is mere coincidence; the colon was _not_ chosen because it\n> conveniently turns the results list into valid object references.  A\n> comma could have been instead, or even a \\t.\n\nNot necessarily.  If the user is asking the question in a more\nnatural way (I want to see where in 'next' branch's tip commit hits\nappear, by the way, I know I am only interested in builtin/ so I'd\ngive pathspec as well when I am asking this question), the output\ndoes give <commit> <colon> <path>, so it is more than coincidence.\n\nI do not think it is worth doing only for this particular use case,\nbut it might be a good change to allow A:B:C to be parsed as a\nproper extended SHA-1 expression and make it yield\n\n\tgit rev-parse $(git rev-parse $(git rev-parse A):B):C\n\nRight now, \"B:C\" is used as a path inside tree-ish \"A\", but I think\nwe can safely fall back, when path B:C does not appear in tree-ish\nA, to see if path B appears in it and is a tree, and then turn it\ninto a look-up of path C in that tree A:B.\n"},{"id":"225919","messageId":"CABURp0r46C84pPptecDmLBHuO2Z+vXAm26JRA+HVcF9KvT_NyA@mail.gmail.com","threadId":"34762","inReplyTo":"xmqqbo4kicsm.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-08-26T17:45:30Z","receivedAt":"2013-08-26T17:45:30Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Aug 26, 2013 at 1:26 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Phil Hord <phil.hord@gmail.com> writes:\n>\n>>> If your justification were \"above says 'there may be a readon why\n>>> the user wanted to ask it in that way', i.e. 'find in this tree\n>>> object HEAD:some/path and report where hits appear', but the reason\n>>> can only be from laziness and/or broken script and the user always\n>>> wants the answer from within the top-level tree-ish\", then that\n>>> argument may make some sense. You need to justify why it is OK to\n>>> lose information in the answer by rewriting the colon that separates\n>>> the question (\"in this tree object\") and the answer (\"at this path\n>>> relative to the tree object given\").\n>>>\n>>> Whether you rewrite the input or the output is not important; you\n>>> are trying to give an answer to a different question, which is what\n>>> I find questionable.\n>>\n>> Ok, so if I can summarize what I am inferring from your objection:\n>>\n>>  1. The (tree-path, found-path) pair is useful information to get back\n>> from git-grep.\n>\n> At least that was the intent. I can be persuaded that your change\n> will not break anybody if you successfully argue that it is not a\n> useful information, though.\n\nAnyone who is interested in the matched trees from the original\ncommand-line only needs to compare the matched paths' prefixes with\nthe original args to see which one is responsible for each hit.  But\nthis is not convincing to me because they may not know the original\nargs to the grep command.\n\nI do not know if this a good reason to keep supporting this mode,\nthough.  I can just as easily see some script being confused by four\ncolons in\n\n    origin/master:some/:path/file.c:1:int main()\n\ninstead of only three that he is used to because someone passed in a\nlonger tree-path than expected.\n\nI don't know if I can make that argument.\n\nI think I _can_ argue that the colon separator here is historically\njust a part of the filename because it is not affected by \"--null\".\n\n>>  2. A colon is used to delimit these pieces of information, just as a\n>> colon is used to delimit the filename from the matched-line results.\n>>\n>>  3. The fact that the colon is also the separator used in object refs\n>> is mere coincidence; the colon was _not_ chosen because it\n>> conveniently turns the results list into valid object references.  A\n>> comma could have been instead, or even a \\t.\n>\n> Not necessarily.  If the user is asking the question in a more\n> natural way (I want to see where in 'next' branch's tip commit hits\n> appear, by the way, I know I am only interested in builtin/ so I'd\n> give pathspec as well when I am asking this question), the output\n> does give <commit> <colon> <path>, so it is more than coincidence.\n>\n> I do not think it is worth doing only for this particular use case,\n> but it might be a good change to allow A:B:C to be parsed as a\n> proper extended SHA-1 expression and make it yield\n>\n>         git rev-parse $(git rev-parse $(git rev-parse A):B):C\n>\n> Right now, \"B:C\" is used as a path inside tree-ish \"A\", but I think\n> we can safely fall back, when path B:C does not appear in tree-ish\n> A, to see if path B appears in it and is a tree, and then turn it\n> into a look-up of path C in that tree A:B.\n\nThat would also solve this problem, usually.  But I don't like it\nnearly as much as my patch, and I agree it seems extreme for this one\ncorner-case.\n\nPhil\n"},{"id":"225953","messageId":"xmqqhaebhj3u.fsf@gitster.dls.corp.google.com","threadId":"34762","inReplyTo":"xmqqbo4kicsm.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-27T04:07:33Z","receivedAt":"2013-08-27T04:07:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Not necessarily.  If the user is asking the question in a more\n> natural way (I want to see where in 'next' branch's tip commit hits\n> appear, by the way, I know I am only interested in builtin/ so I'd\n> give pathspec as well when I am asking this question), the output\n> does give <commit> <colon> <path>, so it is more than coincidence.\n\nThis part needs to be qualified.  \"Natural\" is of course in the eyes\nof beholder.  If we assume that your #1 holds true (i.e. the tuple\n<in which tree object are we reporting, what path we saw hits> is\nimportant and merging them into one <in what blob we saw hits> lose\ninformation), then it is natural to ask \"inside origin/master tree,\nwhere do I have hits?  By the way, I am only interested in builtin/\"\nand get \"origin/master:builtin/pack-objects.c\" as an answer (this is\nfrom your earlier example), than asking \"inside origin/master:builtin\ntree, where do I have hits?\"\n\nIf we do not consider #1 is false and the tree information can be\ndiscarded, then it does not matter if we converted the colon after\norigin/master to slash when we answer the latter question, and the\nlatter question stops being unnatural.\n\n> ...\n> but it might be a good change to allow A:B:C to be parsed as a\n> proper extended SHA-1 expression and make it yield\n>\n> \tgit rev-parse $(git rev-parse $(git rev-parse A):B):C\n>\n> Right now, \"B:C\" is used as a path inside tree-ish \"A\", but I think\n> we can safely fall back, when path B:C does not appear in tree-ish\n> A, to see if path B appears in it and is a tree, and then turn it\n> into a look-up of path C in that tree A:B.\n\nAnd if we want to keep the <tree, path> tuple, but still want to\nmake it easier to work with the output, allowing A:B:C to be parsed\nas an extended SHA-1 expression would be a reasonable solution, not\na work-around. The answer is given to the question asked in either\nway (either \"in origin/master, but limited to these pathspecs\" or\n\"in the tree origin/master:builtin/\") without losing information,\nbut the issue you had is that the answer to the latter form of\nquestion is not understood by the object name parser, which I\npersonally think is a bug.\n"},{"id":"225987","messageId":"CABURp0r6neiqhOA=JsT67Oxr-zUNLpsr71bVc7F_hWWM61KoGQ@mail.gmail.com","threadId":"34762","inReplyTo":"xmqqhaebhj3u.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH] Fix path prefixing in grep_object","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-08-27T11:54:34Z","receivedAt":"2013-08-27T11:54:34Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Aug 27, 2013 at 12:07 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Not necessarily.  If the user is asking the question in a more\n>> natural way (I want to see where in 'next' branch's tip commit hits\n>> appear, by the way, I know I am only interested in builtin/ so I'd\n>> give pathspec as well when I am asking this question), the output\n>> does give <commit> <colon> <path>, so it is more than coincidence.\n>\n> This part needs to be qualified.  \"Natural\" is of course in the eyes\n> of beholder.  If we assume that your #1 holds true (i.e. the tuple\n> <in which tree object are we reporting, what path we saw hits> is\n> important and merging them into one <in what blob we saw hits> lose\n> information),\n\n\"My #1\" is really \"what I inferred from your statements.\"  I did not\nthink the tuple was important, but I agree that may be my\nshortsightedness.  If the tuple is important, then it seems to me that\nthe --null behavior is a bug (the colon is left intact); but changing\nit now seems senseless or harmful.\n\n> then it is natural to ask \"inside origin/master tree,\n> where do I have hits?  By the way, I am only interested in builtin/\"\n> and get \"origin/master:builtin/pack-objects.c\" as an answer (this is\n> from your earlier example), than asking \"inside origin/master:builtin\n> tree, where do I have hits?\"\n>\n> If we do not consider #1 is false and the tree information can be\n> discarded, then it does not matter if we converted the colon after\n> origin/master to slash when we answer the latter question, and the\n> latter question stops being unnatural.\n>\n>> ...\n>> but it might be a good change to allow A:B:C to be parsed as a\n>> proper extended SHA-1 expression and make it yield\n>>\n>>       git rev-parse $(git rev-parse $(git rev-parse A):B):C\n>>\n>> Right now, \"B:C\" is used as a path inside tree-ish \"A\", but I think\n>> we can safely fall back, when path B:C does not appear in tree-ish\n>> A, to see if path B appears in it and is a tree, and then turn it\n>> into a look-up of path C in that tree A:B.\n>\n> And if we want to keep the <tree, path> tuple, but still want to\n> make it easier to work with the output, allowing A:B:C to be parsed\n> as an extended SHA-1 expression would be a reasonable solution, not\n> a work-around. The answer is given to the question asked in either\n> way (either \"in origin/master, but limited to these pathspecs\" or\n> \"in the tree origin/master:builtin/\") without losing information,\n> but the issue you had is that the answer to the latter form of\n> question is not understood by the object name parser, which I\n> personally think is a bug.\n\nI am beginning to agree, though we discovered some other weird output\nfrom grep which also does not parse. (origin/master:../relative/path).\n\nIt seems that fixing this bug could be very confusing for\nget_sha1_with_context unless the context was rewritten to match the\ntraditional syntax.\n\nP\n"}]}