On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi <stefanha@redhat.com> writes:
> 
> > v2.9.3::Makefile may convey that the user originally provided v2.9.3:
> > but is that actually useful information?
> 
> You are either asking a wrong question, or asking a wrong person
> (i.e. Git) the question.  The real question is why the user added a
> colon at the end, when "v2.9.3" alone would have sufficed.  What did
> the user want to get out of giving an extra colon like "v2.9.3:"?
> 
> One answer I can think of is that it is a degenerate case of [2/2],
> i.e. if "v2.9.3:t" were an appropriate way to look in the subtree
> "t" of "v2.9.3", "v2.9.3:" would be the appropriate way to look in
> the whole tree of "v2.9.3".
> 
> I understand, from your response to my comment in the thread for
> [2/2], that the reason why "v2.9.3:t" was used in the example was
> because you felt uncomfortable with using pathspec.  
> 
> That's superstition.
> 
> My only piece of advice to folks who feel that way is to learn Git
> more and get comfortable.  You can do neat things like
> 
>    $ git grep -e pattern rev -- t ':!t/helper/'
> 
> that you cannot do with "rev:t", for example ;-)

Neat, thanks for showing the path exclusion syntax.  I wasn't aware of
it.

> All examples we saw so far are the ones that the user used the colon
> syntax when it is more natural to express the command without it.  I
> am hesitant to see the behaviour of the command changed to appease
> such suboptimal use cases if it requires us to discard a bit of
> information, when we haven't established it is OK to lose.
> 
> There may be a case
> 
>  (1) where the colon syntax is the most natural thing to use, AND
>      script reading the output that used that syntax is forced to do
>      unnecessary work because "git grep" parrots the colon
>      literally, instread of being more intelligent about it
>      (i.e. omitting or substituting with slash when the input is a
>      tree object, not a tree-ish, as discussed in the thread).
> 
>  (2) where the colon syntax is the most natural thing, AND script
>      reading the output WANTS to see the distinction in the input
>      (remember, "git grep" can take more than one input tree).
> 
> We haven't seen either of the above two in the discussion, so the
> discussion so far is not sufficient to support the change being
> proposed in this RFC, which requires that it is safe to assume that
> (1) is the only case where the input is a raw tree (or the input
> contains a colon) and (2) will never happen.
> 
> So I am still mildly negative on the whole thing.

Avoiding the colon syntax avoids the whole issue for my use case.

I still think git-grep(1)'s output would be more useful if it used valid
git rev:path syntax in all cases.