kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Jeff King	df714f81a7	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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Johannes Sixt	b3325dfc64	t2019: skip test requiring '' in a file name non Windows A test case introduced by `ae454f61` (Add tests for wildcard "path vs ref" disambiguation) allocates a file named '.c'. This does not work on Windows, because the OS forbids file names containing wildcard characters. The test case fails where the shell attempts to allocate the file. Skip the test on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Nguyễn Thái Ngọc Duy	ae454f6125	Add tests for wildcard "path vs ref" disambiguation Commit `28fcc0b` (pathspec: avoid the need of "--" when wildcard is used - 2015-05-02) changes how the disambiguation rules work. This patch adds some tests to demonstrate, basically, if wildcard characters are in an argument: - if the argument is valid extended sha-1 syntax, "--" must be used - otherwise the argument is considered a path, even without "--" And wildcard can appear in extended sha-1 syntax, either as part of regex in ":/<regex>" or as the literal path in ":<path>". The latter case is less likely to happen in real world. But if you do ":/" a lot, you may need to type "--" more. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	d3bd0425b2	i18n: use test_i18ngrep in lib-httpd and t2019 Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Ævar Arnfjörð Bjarmason	6b3d83efac	t2019-checkout-ambiguous-ref.sh: depend on C_LOCALE_OUTPUT The t2019-checkout-ambiguous-ref.sh tests added in v1.7.4.3~12^2 examines the output for a translatable string, and must be marked with C_LOCALE_OUTPUT; otherwise, GETTEXT_POISON=YesPlease tests will break. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Junio C Hamano	6c74ce8c7d	Rename t2019 with typo "amiguous" that meant "ambiguous" Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Junio C Hamano	0cb6ad3c3d	checkout: fix bug with ambiguous refs The usual dwim_ref lookup prefers tags to branches. Because checkout primarily works on branches, though, we switch that behavior to prefer branches. However, there was a bug in the implementation in which we used lookup_commit_reference (which used the regular lookup rules) to get the actual commit to checkout. Checking out an ambiguous ref therefore ended up putting us in an extremely broken state in which we wrote the branch ref into HEAD, but actually checked out the tree for the tag. This patch fixes the bug by always attempting to pull the commit to be checked out from the branch-ified version of the name we were given. Patch by Junio, tests and commit message from Jeff King. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago