Stefan Hajnoczi <stefanha@xxxxxxxxxx> 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 ;-)
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.