> > HEAD:/some/path/to/foo.txt > > HEAD:some/path/to/foo.txt > > With my patch it prints the latter. > > This is because get_sha1_with_context("HEAD:"...) returns an empty > 'path' string. The code decides to use ':' as the delimiter in that > case, but it sees there already is one at the end of "HEAD:".
A 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): $ git grep -l cache HEAD:./ | head -1 HEAD:./:.gitignore $ cd Documentation $ git grep -l cache HEAD | head -1 HEAD:CodingGuidelines $ git grep -l cache HEAD:Documentation/CodingGuidelines ../HEAD:Documentation/CodingGuidelines (woah!) Sorry that I don't yet have anything useful to suggest! But I can tell the story of my use case: I 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. Jonathon Mah m...@jonathonmah.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html