[RFC/PATCH] Fix path prefixing in grep_object

When the pathspec given to grep includes a tree name, the full
name of matched files is assembled using colon as a separator.
If the pathspec includes a tree name, it should use a slash
instead.

Check if the pathspec already names a tree and ref (including
a colon) and use a slash if so.
---

I'm not sure about the detection I used here.  It works, but it is
not terribly robust.  Is there a better way to handle this?  Maybe
something like 'prefix_pathspec(name,"");'.

 builtin/grep.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/builtin/grep.c b/builtin/grep.c
index 03bc442..d0deae4 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c

@@ -480,8 +480,9 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,
 		len = name ? strlen(name) : 0;
 		strbuf_init(&base, PATH_MAX + len + 1);
 		if (len) {
+			int has_colon = !!strchr(name,':');
 			strbuf_add(&base, name, len);
-			strbuf_addch(&base, ':');
+			strbuf_addch(&base, has_colon?'/':':');
 		}
 		init_tree_desc(&tree, data, size);
 		hit = grep_tree(opt, pathspec, &tree, &base, base.len,

-- 
1.8.4.557.g34b3a2e

On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord [off-list ref] wrote:

When the pathspec given to grep includes a tree name, the full
name of matched files is assembled using colon as a separator.
If the pathspec includes a tree name, it should use a slash
instead.

Check if the pathspec already names a tree and ref (including
a colon) and use a slash if so.

I think I used lots of wrong terminology there.  What do I call these
things?

HEAD:path is a tree.

HEAD is a commit name.

Maybe like this?

  When a tree is given to grep, the full name of matched files
  is assembled using colon as a separator.

  If the tree name includes an object name, as in
  HEAD:some/path, it should use a slash instead.

Phil

On Sat, Aug 24, 2013 at 09:35:58PM -0400, Phil Hord wrote:

When the pathspec given to grep includes a tree name, the full
name of matched files is assembled using colon as a separator.
If the pathspec includes a tree name, it should use a slash
instead.

Check if the pathspec already names a tree and ref (including
a colon) and use a slash if so.

Makes sense.

I'm not sure about the detection I used here.  It works, but it is
not terribly robust.  Is there a better way to handle this?  Maybe
something like 'prefix_pathspec(name,"");'.

I think the information you want has been thrown away by the time we get
to grep_object. Only get_sha1 knows whether the name was really a direct
tree reference or if it had to traverse paths.

So we are necessarily reconstructing based on what we know of the
syntax. And I think that your rule is OK, because we know that refnames
cannot contain a colon. So even though pathnames can, we do not have to
care; we only want to know "is there a path in the name", and if we have
at least one colon, the answer is yes.

 builtin/grep.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

A test would be nice. Both to make sure we do not re-break it, and because
it helps demonstrate the problem very easily (it took me a minute to
figure out what was going on from your description).

Please use whitespace with your ternary operator. The '/':':' made me
think I was reading Perl for a minute. :)

-Peff

Jeff King wrote:

So we are necessarily reconstructing based on what we know of the
syntax. And I think that your rule is OK, because we know that refnames
cannot contain a colon.

What happens with expressions like HEAD^{/test:}?

Jonathan

On Sat, Aug 24, 2013 at 10:41:42PM -0700, Jonathan Nieder wrote:

Jeff King wrote:

quoted

So we are necessarily reconstructing based on what we know of the
syntax. And I think that your rule is OK, because we know that refnames
cannot contain a colon.

What happens with expressions like HEAD^{/test:}?

Ugh, right. Names are more than just refnames.

So I think the only way to do this robustly is to ask get_sha1 to
remember more about what happened. We might even be able to get away
without teaching get_sha1_with_context anything else; it already records
the path, so we should be able to just check whether that is non-empty.

But we use an object_array to store the list of objects, and it has no
room for such a bit. So we'd probably want to refactor that, too.

-Peff