Re: git show doesn't work on file names with square brackets

[Jeff King <peff@peff.net>]

On Mon, Feb 08, 2016 at 12:06:44PM +0700, Duy Nguyen wrote:

> On Sun, Feb 7, 2016 at 10:11 PM, Kirill Likhodedov
> <kirill.likhodedov@jetbrains.com> wrote:
> > Hi Duy,
> >
> >> It's from 28fcc0b (pathspec: avoid the need of "--" when wildcard is
> >> used - 2015-05-02)
> >
> > v2.5.0 is the first release which contains 28fcc0b.
> > I can confirm that older versions of Git work correctly without “--“:
> >
> > # /opt/local/bin/git version
> > git version 1.7.1.1
> > # /opt/local/bin/git show HEAD:bra[ckets].txt
> > asd
> >
> > Looks like a regression?
> 
> No it's a deliberate trade-off. With that change, you can use
> wildcards in pathspec without "--" (e.g. "git log 'a*'" instead of
> "git log -- 'a*'"). And I still believe that happens a lot more often
> than this case. Putting "--" is _the_ way to avoid ambiguation when
> git fails to do it properly. Though in future we may make git smarter
> at solving ambiguation (e.g. it could do glob() to test if a wildcard
> pattern matches any path).

It's still sort-of a regression; we changed the rule and now things that
used to work don't. Using "--" is a good protection, but people who
didn't have to use "--" in some cases now do.

I wonder if we could fix this pretty simply, though, by skipping the
"does it have a wildcard" check when we see a colon in the path. That is
a good indication that we are using one of git's special rev syntaxes
(either "tree:path", or ":path", or ":/search string". That breaks
anybody who really wanted to look for "path:with:colons.*", but that
seems a lot less likely to me.

It doesn't cover:

  git log 'HEAD^{/Merge.*}'

which is similarly affected by 28fcc0b. Perhaps "^{" should be such a
magic string, as well. We can be liberal with such strings as they are
really just limiting the impact of 28fcc0b; we would fall back in those
cases to the usual "can it be resolved, or is it a path?" rule.

-Peff