path: root/builtin
diff options
authorJeff King <>2016-02-10 21:14:46 (GMT)
committerJunio C Hamano <>2016-02-10 21:53:20 (GMT)
commitdf714f81a709dda9552f137ccd2a3510119298ad (patch)
treef2f11693e9ec841e5199fd7adb87e60b1ad702fd /builtin
parent1cc777de6f4396f578e0f5e6b1a5ec23b96a52f0 (diff)
check_filename: tighten dwim-wildcard ambiguity
When specifying both revisions and pathnames, we allow "<rev> -- <pathspec>" to be spelled without the "--" as long as it is not ambiguous. The original logic was something like: 1. Resolve each item with get_sha1(). If successful, we know it can be a <rev>. Verify that it _isn't_ a filename, using verify_non_filename(), and complain of ambiguity otherwise. 2. If get_sha1() didn't succeed, make sure that it _is_ a file, using verify_filename(). If not, complain that it is neither a <rev> nor a <pathspec>. Both verify_filename() and verify_non_filename() rely on check_filename(), which definitely said "yes, this is a file" or "no, it is not" using lstat(). Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used, 2015-05-02) introduced a convenience feature: check_filename() will consider anything with wildcard meta-characters as a possible filename, without even checking the filesystem. This works well for case 2. For such a wildcard, we would previously have died and said "it is neither". Post-28fcc0b, we assume it's a pathspec and proceed. But it makes some instances of case 1 worse. We may have an extended sha1 expression that contains meta-characters (e.g., "HEAD^{/foo.*bar}"), and we now complain that it's also a filename, due to the wildcard characters (even though that wildcard would not match anything in the filesystem). One solution would be to actually expand the pathname and see if it matches anything on the filesystem. But that's potentially expensive, and we do not have to be so rigorous for this DWIM magic (if you want rigor, use "--"). Instead, we can just use different rules for cases 1 and 2. When we know something is a rev, we will complain only if it meets a much higher standard for "this is also a file"; namely that it actually exists in the filesystem. Case 2 remains the same: we use the looser "it could be a filename" standard introduced by 28fcc0b. We can accomplish this by pulling the wildcard logic out of check_filename() and putting it into verify_filename(). Its partner verify_non_filename() does not need a change, since check_filename() goes back to implementing the "higher standard". Besides these two callers of check_filename(), there is one other: git-checkout does a similar DWIM itself. It hits this code path only after get_sha1() has returned failure, making it case 2, which gets the special wildcard treatment. Note that we drop the tests in t2019 in favor of a more complete set in t6133. t2019 was not the right place for them (it's about refname ambiguity, not dwim parsing ambiguity), and the second test explicitly checked for the opposite result of the case we are fixing here (which didn't really make any sense; as shown by the test_must_fail in the test, it would only serve to annoy people). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'builtin')
1 files changed, 2 insertions, 1 deletions
diff --git a/builtin/checkout.c b/builtin/checkout.c
index d34f58e..e5c16af 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -965,7 +965,8 @@ static int parse_branchname_arg(int argc, const char **argv,
int recover_with_dwim = dwim_new_local_branch_ok;
- if (!has_dash_dash && check_filename(NULL, arg))
+ if (!has_dash_dash &&
+ (check_filename(NULL, arg) || !no_wildcard(arg)))
recover_with_dwim = 0;
* Accept "git checkout foo" and "git checkout foo --"