> >     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

$ cd Documentation
$ git grep -l cache HEAD | head -1

$ git grep -l cache HEAD:Documentation/CodingGuidelines

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

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

Reply via email to