]> git.ipfire.org Git - thirdparty/git.git/commit
verify_filename(): handle backslashes in "wildcards are pathspecs" rule
authorJeff King <peff@peff.net>
Sat, 25 Jan 2020 00:00:51 +0000 (19:00 -0500)
committerJunio C Hamano <gitster@pobox.com>
Mon, 27 Jan 2020 18:46:35 +0000 (10:46 -0800)
commit39e21c6ef5221a1dcb8a241f60d7e91d59bd6627
tree514e8845ffbbe2c2764a86d3197e1e187f86fc05
parentb6d4d82bd5a49197d5d2f4f81c08da0d461cfcf1
verify_filename(): handle backslashes in "wildcards are pathspecs" rule

Commit 28fcc0b71a (pathspec: avoid the need of "--" when wildcard is
used, 2015-05-02) allowed:

  git rev-parse '*.c'

without the double-dash. But the rule it uses to check for wildcards
actually looks for any glob special. This is overly liberal, as it means
that a pattern that doesn't actually do any wildcard matching, like
"a\b", will be considered a pathspec.

If you do have such a file on disk, that's presumably what you wanted.
But if you don't, the results are confusing: rather than say "there's no
such path a\b", we'll quietly accept it as a pathspec which very likely
matches nothing (or at least not what you intended). Likewise, looking
for path "a\*b" doesn't expand the search at all; it would only find a
single entry, "a*b".

This commit switches the rule to trigger only when glob metacharacters
would expand the search, meaning both of those cases will now report an
error (you can still disambiguate using "--", of course; we're just
tightening the DWIM heuristic).

Note that we didn't test the original feature in 28fcc0b71a at all. So
this patch not only tests for these corner cases, but also adds a
regression test for the existing behavior.

Reported-by: David Burström <davidburstrom@spotify.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup.c
t/t1506-rev-parse-diagnosis.sh