summaryrefslogtreecommitdiff
path: root/t/t4208-log-magic-pathspec.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-07-24Merge branch 'wc/find-commit-with-pattern-on-detached-head'Libravatar Junio C Hamano1-0/+26
"git rev-parse ':/substring'" did not consider the history leading only to HEAD when looking for a commit with the given substring, when the HEAD is detached. This has been fixed. * wc/find-commit-with-pattern-on-detached-head: sha1-name.c: for ":/", find detached HEAD commits
2018-07-12sha1-name.c: for ":/", find detached HEAD commitsLibravatar William Chargin1-0/+26
This patch broadens the set of commits matched by ":/<pattern>" to include commits reachable from HEAD but not any named ref. This avoids surprising behavior when working with a detached HEAD and trying to refer to a commit that was recently created and only exists within the detached state. If multiple worktrees exist, only the current worktree's HEAD is considered reachable. This is consistent with the existing behavior for other per-worktree refs: e.g., bisect refs are considered reachable, but only within the relevant worktree. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21t4208: abstract away SHA-1-specific constantsLibravatar brian m. carlson1-1/+2
Adjust the test so that it computes variables for object IDs instead of using hard-coded hashes. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-05pathspec: only match across submodule boundaries when requestedLibravatar Brandon Williams1-0/+19
Commit 74ed43711fd (grep: enable recurse-submodules to work on <tree> objects, 2016-12-16) taught 'tree_entry_interesting()' to be able to match across submodule boundaries in the presence of wildcards. This is done by performing literal matching up to the first wildcard and then punting to the submodule itself to perform more accurate pattern matching. Instead of introducing a new flag to request this behavior, commit 74ed43711fd overloaded the already existing 'recursive' flag in 'struct pathspec' to request this behavior. This leads to a bug where whenever any other caller has the 'recursive' flag set as well as a pathspec with wildcards that all submodules will be indicated as matches. One simple example of this is: git init repo cd repo git init submodule git -C submodule commit -m initial --allow-empty touch "[bracket]" git add "[bracket]" git commit -m bracket git add submodule git commit -m submodule git rev-list HEAD -- "[bracket]" Fix this by introducing the new flag 'recurse_submodules' in 'struct pathspec' and using this flag to determine if matches should be allowed to cross submodule boundaries. This fixes https://github.com/git-for-windows/git/issues/1371. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29verify_filename(): treat ":(magic)" as a pathspecLibravatar Jeff King1-0/+13
For commands that take revisions and pathspecs, magic pathspecs like ":(exclude)foo" require the user to specify a disambiguating "--", since they do not match a file in the filesystem, like: git grep foo -- :(exclude)bar This makes them more annoying to use than they need to be. We loosened the rules for wildcards in 28fcc0b71 (pathspec: avoid the need of "--" when wildcard is used, 2015-05-02). Let's do the same for pathspecs with long-form magic. We already handle the short-forms ":/" and ":^" specially in check_filename(), so we don't need to handle them here. And in fact, we could do the same with long-form magic, parsing out the actual filename and making sure it exists. But there are a few reasons not to do it that way: - the parsing gets much more complicated, and we'd want to hand it off to the pathspec code. But that code isn't ready to do this kind of speculative parsing (it's happy to die() when it sees a syntactically invalid pathspec). - not all pathspec magic maps to a filesystem path. E.g., :(attr) should be treated as a pathspec regardless of what is in the filesystem - we can be a bit looser with ":(" than with the short-form ":/", because it is much less likely to have a false positive. Whereas ":/" also means "search for a commit with this regex". Note that because the change is in verify_filename() and not in its helper check_filename(), this doesn't affect the verify_non_filename() case. I.e., if an item that matches our new rule doesn't resolve as an object, we may fallback to treating it as a pathspec (rather than complaining it doesn't exist). But if it does resolve (e.g., as a file in the index that starts with an open-paren), we won't then complain that it's also a valid pathspec. This matches the wildcard-exception behavior. And of course in either case, one can always insert the "--" to get more precise results. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29check_filename(): handle ":^" path magicLibravatar Jeff King1-0/+13
We special-case "git log :/foo" to work when "foo" exists in the working tree. But :^ (and its alias :!) do not get the same treatment, requiring the user to supply a disambiguating "--". Let's make them work without requiring the user to type the "--". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29t4208: add check for ":/" without matching fileLibravatar Jeff King1-0/+6
The DWIM magic in check_filename() doesn't just recognize ":/". It actually makes sure that the file it points to exists. t4208 checks only the case where the path is present, not the opposite. Since the next patches will be touching this area, let's add a test to make sure it continues working. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: setup: mark strings for translationLibravatar Vasco Almeida1-2/+2
Update tests that compare the strings newly marked for translation to succeed when running under GETTEXT_POISON. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-22Fix calling parse_pathspec with no paths nor PATHSPEC_PREFER_* flagsLibravatar Nguyễn Thái Ngọc Duy1-0/+15
When parse_pathspec() is called with no paths, the behavior could be either return no paths, or return one path that is cwd. Some commands do the former, some the latter. parse_pathspec() itself does not make either the default and requires the caller to specify either flag if it may run into this situation. I've grep'd through all parse_pathspec() call sites. Some pass neither, but those are guaranteed never pass empty path to parse_pathspec(). There are two call sites that may pass empty path and are fixed with this patch. [jc: added a test from Antoine's bug report] Reported-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21Update :/abc ambiguity checkLibravatar Nguyễn Thái Ngọc Duy1-2/+15
:/abc may mean two things: - as a revision, it means the revision that has "abc" in commit message. - as a pathpec, it means "abc" from root. Currently we see ":/abc" as a rev (most of the time), but never see it as a pathspec even if "abc" exists and "git log :/abc" will gladly take ":/abc" as rev even it's ambiguous. This patch makes it: - ambiguous when "abc" exists on worktree - a rev if abc does not exist on worktree - a path if abc is not found in any commits (although better use "--" to avoid ambiguation because searching through commit DAG is expensive) A plus from this patch is, because ":/" never matches anything as a rev, it is never considered a valid rev and because root directory always exists, ":/" is always unambiguously seen as a pathspec. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-10t3703, t4208: add test cases for magic pathspecLibravatar Nguyễn Thái Ngọc Duy1-0/+36
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>