# Re: [PATCH 2/2] grep: use slash for path delimiter, not colon

2 messages from 2013-09-22 to 2013-09-24. Participants: Jonathon Mah, Jeff King.
Thread: https://gitlist.dev/t/34996

## Jonathon Mah, 2013-09-22 19:15

Subject: Re: [PATCH 2/2] grep: use slash for path delimiter, not colon
Message-ID: <99F7DE7C-A8D7-4EDF-B9C5-8DB143BFDB53@me.com>
URL: https://gitlist.dev/e/99F7DE7C-A8D7-4EDF-B9C5-8DB143BFDB53%40me.com

```
> >     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
me@JonathonMah.com

```

## Jeff King, 2013-09-24 06:57

Subject: Re: [PATCH 2/2] grep: use slash for path delimiter, not colon
Message-ID: <20130924065751.GD5875@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20130924065751.GD5875%40sigill.intra.peff.net
In-Reply-To: <99F7DE7C-A8D7-4EDF-B9C5-8DB143BFDB53@me.com>

```
On Sun, Sep 22, 2013 at 12:15:21PM -0700, Jonathon Mah wrote:

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

If you haven't read the side thread starting at [1], there are some
arguments that git-grep is doing the right thing already.  I think there
are a few issues at play here:

> $ git grep -l cache HEAD:./ | head -1
> HEAD:./:.gitignore

As you show, using a colon separator from a tree-ish that contains a
partial path looks bad.  The downside of turning this into a slash,
though, is that you lose the information of the tree-ish. See [2].

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

Grepping from a subdirectory produces relative paths that look like real
tree:path specifications, but aren't. Showing the full path would
potentially be cluttering if you are in a deep directory.  These days we
have the "./" syntax, though, so we could perhaps output:

  HEAD:./CodingGuidelines

which is succinct but can be used to access the path in the tree (and
makes more clear to the user that we have only grepped in the current
subdirectory).

> $ git grep -l cache HEAD:Documentation/CodingGuidelines
> ../HEAD:Documentation/CodingGuidelines
> (woah!)

That one just seems nonsensical and buggy to me. We should not be
applying ".." at all to a blob spec like this.

-Peff

[1] http://thread.gmane.org/gmane.comp.version-control.git/232892/focus=232980

[2] http://thread.gmane.org/gmane.comp.version-control.git/232892/focus=233004

```