Junio C Hamano <[email protected]> writes:
> Jonathan Nieder <[email protected]> writes:
>
>> I think Phil meant that when "git grep" is asked to search within
>> "HEAD:some/path", filenames tacked on at the end should be appended
>> with a '/' separator instead of the usual ':' (e.g.,
>> "HEAD:some/path/inner/path.c", not "HEAD:some/path:inner/path.c").
>
> Ah, OK.
>
> I am not sure if we have a proper hint in the revision parser
> machinery, but it may not be too hard to teach rev-cmdline interface
> to keep that kind of information (i.e. "This tree object name is a
> result of parsing '<tree-ish>:path' syntax").
Actually, having thought about this a bit more, I am no longer sure
if this is even a good idea to begin with.
An output line that begins with HEAD:some/path:inner/path.c from
"git grep" is an answer to this question: find the given pattern in
a tree-ish specified with "HEAD:some/path".
On the other hand, HEAD:some/path/inner/path.c is an answer to a
different question: find the pattern in a tree-ish specified with
"HEAD". The question may optionally be further qualified with "but
limit the search to some/path". Both the question and its answer
are more intuitive than the former one.
And we have a nice way to ask that question directly, i.e.
$ git grep -e pattern HEAD some/path
which can be extended naturally to more than one path, e.g.
$ git grep -e pattern HEAD some/path another/hierarchy
without having to repeat HEAD: part again for each path.
If the user asked the question of the former form, i.e.
$ git grep -e pattern HEAD:some/path
there may be a reason why the user wanted to ask it in that
(somewhat strange) way. I am not 100% sure if it is a good idea to
give an answer to a question different from what the user asked by
internally rewriting the question to
$ git grep -e pattern HEAD -- some/path
So...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
