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