summaryrefslogtreecommitdiff
path: root/t/t6018-rev-list-glob.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-09-26tests: avoid variations of the `master` branch nameLibravatar Johannes Schindelin1-3/+3
The term `master` has a loaded history that serves as a constant reminder of racial injustice. The Git project has no desire to perpetuate this and already started avoiding it. The test suite uses variations of this name for branches other than the default one. Apart from t3200, where we just addressed this in the previous commit, those instances can be renamed in an automated manner because they do not require any changes outside of the test script, so let's do that. Seeing as the touched branches have very little (if anything) to do with the default branch, we choose to use a completely separate naming scheme: `topic_<number>` (it cannot be `topic-<number>` because t5515 uses the `test_oid` machinery with the term, and that machinery uses shell variables internally, whose names cannot contain dashes). This trick was performed by this (GNU) sed invocation: $ sed -i 's/master\([a-z0-9]\)/topic_\1/g' t/t*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26revision: set rev_input_given in handle_revision_arg()Libravatar Jeff King1-0/+5
Commit 7ba826290a (revision: add rev_input_given flag, 2017-08-02) added a flag to rev_info to tell whether we got any revision arguments. As explained there, this is necessary because some revision arguments may not produce any pending traversal objects, but should still inhibit default behaviors (e.g., a glob that matches nothing). However, it only set the flag in the globbing code, but not for revisions we get on the command-line or via stdin. This leads to two problems: - the command-line code keeps its own separate got_rev_arg flag; this isn't wrong, but it's confusing and an extra maintenance burden - even specifically-named rev arguments might end up not adding any pending objects: if --ignore-missing is set, then specifying a missing object is a noop rather than an error. And that leads to some user-visible bugs: - when deciding whether a default rev like "HEAD" should kick in, we check both got_rev_arg and rev_input_given. That means that "--ignore-missing $ZERO_OID" works on the command-line (where we set got_rev_arg) but not on --stdin (where we don't) - when rev-list decides whether it should complain that it wasn't given a starting point, it relies on rev_input_given. So it can't even get the command-line "--ignore-missing $ZERO_OID" right Let's consistently set the flag if we got any revision argument. That lets us clean up the redundant got_rev_arg, and fixes both of those bugs (but note there are three new tests: we'll confirm the already working git-log command-line case). A few implementation notes: - conceptually we want to set the flag whenever handle_revision_arg() finds an actual revision arg ("handles" it, you might say). But it covers a ton of cases with early returns. Rather than annotating each one, we just wrap it and use its success exit-code to set the flag in one spot. - the new rev-list test is in t6018, which is titled to cover globs. This isn't exactly a glob, but it made sense to stick it with the other tests that handle the "even though we got a rev, we have no pending objects" case, which are globs. - the tests check for the oid of a missing object, which it's pretty clear --ignore-missing should ignore. You can see the same behavior with "--ignore-missing a-ref-that-does-not-exist", because --ignore-missing treats them both the same. That's perhaps less clearly correct, and we may want to change that in the future. But the way the code and tests here are written, we'd continue to do the right thing even if it does. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-18Merge branch 'ra/rev-parse-exclude-glob'Libravatar Junio C Hamano1-3/+57
"rev-parse --exclude=<pattern> --branches=<pattern>" etc. did not quite work, which has been corrected. * ra/rev-parse-exclude-glob: refs: fix some exclude patterns being ignored refs: show --exclude failure with --branches/tags/remotes=glob
2018-11-13Merge branch 'ag/rev-parse-all-exclude-fix'Libravatar Junio C Hamano1-0/+12
"git rev-parse --exclude=* --branches --branches" (i.e. first saying "add only things that do not match '*' out of all branches" and then adding all branches, without any exclusion this time") worked as expected, but "--exclude=* --all --all" did not work the same way, which has been fixed. * ag/rev-parse-all-exclude-fix: rev-parse: clear --exclude list after 'git rev-parse --all'
2018-11-13refs: fix some exclude patterns being ignoredLibravatar Rafael Ascensão1-12/+12
`--exclude` from rev-list and rev-parse fails to exclude references if the next `--branches`, `--tags` or `--remotes` use the optional inclusive glob because those options are implemented as particular cases of `--glob=`, which itself requires that exclude patterns begin with 'refs/'. But it makes sense for `--branches=glob` and friends to be aware that exclusions patterns for them shouldn't be 'refs/<type>/' prefixed, the same way exclude patterns for `--branches` and friends (without the optional glob) already are. Let's record in 'refs.c:struct ref_filter' which context the exclude pattern is tied to, so refs.c:filter_refs() can decide if it should ignore the prefix when trying to match. Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13refs: show --exclude failure with --branches/tags/remotes=globLibravatar Rafael Ascensão1-3/+57
The documentation of `--exclude=` option from rev-list and rev-parse explicitly states that exclude patterns *should not* start with 'refs/' when used with `--branches`, `--tags` or `--remotes`. However, following this advice results in refereces not being excluded if the next `--branches`, `--tags`, `--remotes` use the optional inclusive glob. Demonstrate this failure. Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-01rev-parse: clear --exclude list after 'git rev-parse --all'Libravatar Andreas Gruenbacher1-0/+12
Commit [1] added the --exclude option to revision.c. The --all, --branches, --tags, --remotes, and --glob options clear the exclude list. Shortly therafter, commit [2] added the same to 'git rev-parse', but without clearing the exclude list for the --all option. [1] e7b432c52 ("revision: introduce --exclude=<glob> to tame wildcards", 2013-08-30) [2] 9dc01bf06 ("rev-parse: introduce --exclude=<glob> to tame wildcards", 2013-11-01) Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-22rev-list: make empty --stdin not an errorLibravatar Jeff King1-1/+1
When we originally did the series that contains 7ba826290a (revision: add rev_input_given flag, 2017-08-02) the intent was that "git rev-list --stdin </dev/null" would similarly become a successful noop. However, an attempt at the time to do that did not work[1]. The problem is that rev_input_given serves two roles: - it tells rev-list.c that it should not error out - it tells revision.c that it should not have the "default" ref kick (e.g., "HEAD" in "git log") We want to trigger the former, but not the latter. This is technically possible with a single flag, if we set the flag only after revision.c's revs->def check. But this introduces a rather subtle ordering dependency. Instead, let's keep two flags: one to denote when we got actual input (which triggers both roles) and one for when we read stdin (which triggers only the first). This does mean a caller interested in the first role has to check both flags, but there's only one such caller. And any future callers might want to make the distinction anyway (e.g., if they care less about erroring out, and more about whether revision.c soaked up our stdin). In fact, we already keep such a flag internally in revision.c for this purpose, so this is really just exposing that to the caller (and the old function-local flag can go away in favor of our new one). [1] https://public-inbox.org/git/20170802223416.gwiezhbuxbdmbjzx@sigill.intra.peff.net/ Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-22t6018-rev-list-glob: fix 'empty stdin' testLibravatar SZEDER Gábor1-1/+1
Prior to d3c6751b18 (tests: make use of the test_must_be_empty function, 2018-07-27), in the test 'rev-list should succeed with empty output on empty stdin' in 't6018-rev-list-glob' the empty 'expect' file served dual purpose: besides specifying the expected output, as usual, it also served as empty input for 'git rev-list --stdin'. Then d3c6751b18 came along, and, as part of the conversion to 'test_must_be_empty', removed this empty 'expect' file, not realizing its secondary purpose. Redirecting stdin from the now non-existing file failed the test, but since this test expects failure in the first place, this issue went unnoticed. Redirect 'git rev-list's stdin explicitly from /dev/null to provide empty input. (Strictly speaking we don't need this redirection, because the test script's stdin is already redirected from /dev/null anyway, but I think it's better to be explicit about it.) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30tests: make use of the test_must_be_empty functionLibravatar Ævar Arnfjörð Bjarmason1-8/+4
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-02rev-list: don't show usage when we see empty ref patternsLibravatar Jeff King1-3/+3
If the user gives us no starting point for a traversal, we want to complain with our normal usage message. But if they tried to do so with "--all" or "--glob", but that happened not to match any refs, the usage message isn't helpful. We should just give them the empty output they asked for instead. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-02t6018: flesh out empty input/output rev-list testsLibravatar Jeff King1-11/+9
In 751a2ac6e (rev-list --exclude: tests, 2013-11-01), we added a few tests for handling "empty" inputs with rev-list (i.e., where the user gave us some pattern but it turned out not to queue any objects for traversal), all of which were marked as failing. In preparation for working on this area of the code, let's give each test a more descriptive name. Let's also include one more case which we should cover: feeding a --glob pattern that doesn't match anything. We can also drop the explanatory comment; we'll be converting these to expect_success in the next few patches, so the discussion isn't necessary. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11Spelling fixesLibravatar Ville Skyttä1-1/+1
<BAD> <CORRECTED> accidently accidentally commited committed dependancy dependency emtpy empty existance existence explicitely explicitly git-upload-achive git-upload-archive hierachy hierarchy indegee indegree intial initial mulitple multiple non-existant non-existent precendence. precedence. priviledged privileged programatically programmatically psuedo-binary pseudo-binary soemwhere somewhere successfull successful transfering transferring uncommited uncommitted unkown unknown usefull useful writting writing Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-01rev-parse: introduce --exclude=<glob> to tame wildcardsLibravatar Junio C Hamano1-0/+12
Teach "rev-parse" the same "I'm going to glob, but omit the ones that match these patterns" feature as "rev-list". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-01rev-list --exclude: testsLibravatar Junio C Hamano1-0/+42
Add tests for the --exclude=<glob> feature. A few tests are added for cases where use of globbing and "--exclude" results in no positive revisions: * "--exclude=<glob>" before "--all" etc. resulted in no results; * "--stdin" is used but no input was given; * "--all" etc. is used but no matching refs are found. Currently, we fail such a request with the same error message we would give to a command line that does not specify any positive revision (e.g. "git rev-list<ENTER>"). We may want to treat these cases differently and not error out, but the logic to detect that would be common to all of them, so I'd leave it outside this topic for now, and stop at adding these tests as food-for-thought. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-21revisions: allow --glob and friends in parse_options-enabled commandsLibravatar Jonathan Nieder1-0/+50
As v1.6.0-rc2~42 (2008-07-31) explains, even pseudo-options like --not and --glob that need to be parsed in order with revisions should be marked handled by handle_revision_opt to avoid an error when parse_revision_opt callers like "git shortlog" encounter them. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06log: parse separate option for --globLibravatar Matthieu Moy1-0/+6
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27t6018: make sure all tested symbolic names are different revsLibravatar Michael J Gruber1-1/+3
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27t6018: add tests for rev-list's --branches and --tagsLibravatar Michael J Gruber1-0/+13
so that we know when they break. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20rev-parse --branches/--tags/--remotes=patternLibravatar Ilari Liusvaara1-1/+62
Since local branch, tags and remote tracking branch namespaces are most often used, add shortcut notations for globbing those in manner similar to --glob option. With this, one can express the "what I have but origin doesn't?" as: 'git log --branches --not --remotes=origin' Original-idea-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20rev-parse --globLibravatar Ilari Liusvaara1-0/+134
Add --glob=<glob-pattern> option to rev-parse and everything that accepts its options. This option matches all refs that match given shell glob pattern (complete with some DWIM logic). Example: 'git log --branches --not --glob=remotes/origin' To show what you have that origin doesn't. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>