{"thread":{"id":"34996","subject":"Re: [PATCH 2/2] grep: use slash for path delimiter, not colon","startedAt":"2013-09-22T19:15:21Z","lastAt":"2013-09-24T06:57:51Z","messageCount":2,"participants":["Jonathon Mah","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"228037","messageId":"99F7DE7C-A8D7-4EDF-B9C5-8DB143BFDB53@me.com","threadId":"34996","inReplyTo":null,"subject":"Re: [PATCH 2/2] grep: use slash for path delimiter, not colon","fromName":"Jonathon Mah","fromEmail":"jmah@me.com","sentAt":"2013-09-22T19:15:21Z","receivedAt":"2013-09-22T19:15:21Z","isPatch":true,"sender":{"key":"jmah@me.com","avatar":null},"body":"> >     HEAD:/some/path/to/foo.txt\n> >     HEAD:some/path/to/foo.txt\n> \n> With my patch it prints the latter.\n> \n> This is because get_sha1_with_context(\"HEAD:\"...) returns an empty\n> 'path' string.  The code decides to use ':' as the delimiter in that\n> case, but it sees there already is one at the end of \"HEAD:\".\n\nA few days ago I came across the same \"surprising\" output of git-grep, tried to adjust the code to print \"git show\"-able object names, and ran into similar subtleties. I just found this thread, and Jeff's code handles more cases than mine did (I didn't try Phil's initial patch), but I can add some more test cases with non-showable output (again related to git-grep's path scoping):\n\n$ git grep -l cache HEAD:./ | head -1\nHEAD:./:.gitignore\n\n$ cd Documentation\n$ git grep -l cache HEAD | head -1\nHEAD:CodingGuidelines\n\n$ git grep -l cache HEAD:Documentation/CodingGuidelines\n../HEAD:Documentation/CodingGuidelines\n(woah!)\n\nSorry that I don't yet have anything useful to suggest! But I can tell the story of my use case:\n\nI have a large repository (1.6GB bare) which I don't work on, but which contains code that I need to refer to. A checkout is ~600MB and 27k files, which I'd like to avoid (it's redundant data, and would slow down backups of my drive). I found myself \"git-grep\"ping through parts of the tree, looking through the results, and then \"git-show\"ing interesting files. Having a real object name in the grep output allows copy-and-paste of the object path.\n\n\n\nJonathon Mah\nme@JonathonMah.com\n"},{"id":"228139","messageId":"20130924065751.GD5875@sigill.intra.peff.net","threadId":"34996","inReplyTo":"99F7DE7C-A8D7-4EDF-B9C5-8DB143BFDB53@me.com","subject":"Re: [PATCH 2/2] grep: use slash for path delimiter, not colon","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-24T06:57:51Z","receivedAt":"2013-09-24T06:57:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 22, 2013 at 12:15:21PM -0700, Jonathon Mah wrote:\n\n> A few days ago I came across the same \"surprising\" output of git-grep,\n> tried to adjust the code to print \"git show\"-able object names, and\n> ran into similar subtleties. I just found this thread, and Jeff's code\n> handles more cases than mine did (I didn't try Phil's initial patch),\n> but I can add some more test cases with non-showable output (again\n> related to git-grep's path scoping):\n> \n\nIf you haven't read the side thread starting at [1], there are some\narguments that git-grep is doing the right thing already.  I think there\nare a few issues at play here:\n\n> $ git grep -l cache HEAD:./ | head -1\n> HEAD:./:.gitignore\n\nAs you show, using a colon separator from a tree-ish that contains a\npartial path looks bad.  The downside of turning this into a slash,\nthough, is that you lose the information of the tree-ish. See [2].\n\n> $ cd Documentation\n> $ git grep -l cache HEAD | head -1\n> HEAD:CodingGuidelines\n\nGrepping from a subdirectory produces relative paths that look like real\ntree:path specifications, but aren't. Showing the full path would\npotentially be cluttering if you are in a deep directory.  These days we\nhave the \"./\" syntax, though, so we could perhaps output:\n\n  HEAD:./CodingGuidelines\n\nwhich is succinct but can be used to access the path in the tree (and\nmakes more clear to the user that we have only grepped in the current\nsubdirectory).\n\n> $ git grep -l cache HEAD:Documentation/CodingGuidelines\n> ../HEAD:Documentation/CodingGuidelines\n> (woah!)\n\nThat one just seems nonsensical and buggy to me. We should not be\napplying \"..\" at all to a blob spec like this.\n\n-Peff\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/232892/focus=232980\n\n[2] http://thread.gmane.org/gmane.comp.version-control.git/232892/focus=233004\n"}]}