On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote: > Stefan Hajnoczi <stefa...@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.
signature.asc
Description: PGP signature
