path: root/t/
AgeCommit message (Collapse)Author
2021-07-26ref-filter: add %(rest) atomZheNing Hu
%(rest) is a atom used for cat-file batch mode, which can split the input lines at the first whitespace boundary, all characters before that whitespace are considered to be the object name; characters after that first run of whitespace (i.e., the "rest" of the line) are output in place of the %(rest) atom. In order to let "cat-file --batch=%(rest)" use the ref-filter interface, add %(rest) atom for ref-filter. Introduce the reject_atom() to reject the atom %(rest) for "git for-each-ref", "git branch", "git tag" and "git verify-tag". Reviewed-by: Jacob Keller <> Suggected-by: Jacob Keller <> Mentored-by: Christian Couder <> Mentored-by: Hariom Verma <> Signed-off-by: ZheNing Hu <> Signed-off-by: Junio C Hamano <>
2021-02-26Merge branch 'ab/detox-gettext-tests'Junio C Hamano
Removal of GIT_TEST_GETTEXT_POISON continues. * ab/detox-gettext-tests: tests: remove most uses of test_i18ncmp tests: remove last uses of C_LOCALE_OUTPUT tests: remove most uses of C_LOCALE_OUTPUT tests: remove last uses of GIT_TEST_GETTEXT_POISON=false
2021-02-23Merge branch 'bc/signed-objects-with-both-hashes'Junio C Hamano
Signed commits and tags now allow verification of objects, whose two object names (one in SHA-1, the other in SHA-256) are both signed. * bc/signed-objects-with-both-hashes: gpg-interface: remove other signature headers before verifying ref-filter: hoist signature parsing commit: allow parsing arbitrary buffers with headers gpg-interface: improve interface for parsing tags commit: ignore additional signatures when parsing signed commits ref-filter: switch some uses of unsigned long to size_t
2021-02-11tests: remove most uses of test_i18ncmpÆvar Arnfjörð Bjarmason
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-02-11gpg-interface: remove other signature headers before verifyingbrian m. carlson
When we have a multiply signed commit, we need to remove the signature in the header before verifying the object, since the trailing signature will not be over both pieces of data. Do so, and verify that we validate the signature appropriately. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2020-11-19t7[0-4]*: adjust the references to the default branch name "main"Johannes Schindelin
Carefully excluding t7064, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t7[0-4]*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t7[0-4]*.sh && git checkout HEAD -- t7064\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Johannes Schindelin
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ t/ \ t/ t/ \ t/ t/ \ t/ t/ \ t/ \ t/ \ t/ t/ \ t/ \ t/ t/ \ t/ We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-09-16ref-filter: allow merged and no-merged filtersAaron Lipman
Enable ref-filter to process multiple merged and no-merged filters, and extend functionality to git branch, git tag and git for-each-ref. This provides an easy way to check for branches that are "graduation candidates:" $ git branch --no-merged master --merged next If passed more than one merged (or more than one no-merged) filter, refs must be reachable from any one of the merged commits, and reachable from none of the no-merged commits. Signed-off-by: Aaron Lipman <> Signed-off-by: Junio C Hamano <>
2020-03-05tag: use new advice API to check visibilityHeba Waly
change the advise call in tag library from advise() to advise_if_enabled() to construct an example of the usage of the new API. Signed-off-by: Heba Waly <> Signed-off-by: Junio C Hamano <>
2019-12-25Merge branch 'rs/test-cleanup'Junio C Hamano
Test cleanup. * rs/test-cleanup: t6030: don't create unused file t5580: don't create unused file t3501: don't create unused file t7004: don't create unused file t4256: don't create unused file
2019-12-11t7004: don't create unused fileRené Scharfe
msgfile2 became unused with 3968658599 (Make builtin-tag.c use parse_options., 2007-11-09), get rid of it. Signed-off-by: René Scharfe <> Signed-off-by: Junio C Hamano <>
2019-12-01Merge branch 'ma/t7004'Junio C Hamano
Test fix. * ma/t7004: t7004: check existence of correct tag
2019-11-14t7004: check existence of correct tagMartin Ågren
We try to delete the non-existing tag "anothertag", but for the verifications, we check that the tag "myhead" doesn't exist. "myhead" isn't used in this test except for this checking. Comparing to the test two tests earlier, it looks like a copy-paste mistake. Perhaps it's overkill to check that `git tag -d` didn't decide to *create* a tag. But since we're trying to be this careful, let's actually check the correct tag. While we're doing this, let's use a more descriptive tag name instead -- "nonexistingtag" should be obvious. Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2019-11-10Fix spelling errors in names of testsElijah Newren
Reported-by: Jens Schleusener <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2019-06-05tag: add tag.gpgSign config option to force all tags be GPG-signedTigran Mkrtchyan
As many CI/CD tools don't allow to control command line options when executing `git tag` command, a default value in the configuration file will allow to enforce tag signing if required. The new config-file option tag.gpgSign is added to define default behavior of tag signings. To override default behavior the command line option -s, --sign and --no-sign can be used: $ git tag -m "commit message" will generate a GPG signed tag if tag.gpgSign option is true, while $ git tag --no-sign -m "commit message" will skip the signing step. Signed-off-by: Tigran Mkrtchyan <> Signed-off-by: Junio C Hamano <>
2019-05-09tag: fix typo in nested tagging hintDenton Liu
In eea9c1e78f (tag: advise on nested tags, 2019-04-04), tag was taught to hint at the user if a nested tag is made. However, this message had a typo and it said "The object referred to by your new is...", which was missing a "tag" after "new". Fix this message by adding the "tag". Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-04-12tag: advise on nested tagsDenton Liu
Robert Dailey reported confusion on the mailing list about a nested tag which was most likely created by mistake. Jeff King noted that this isn't a very common case and creating a tag-to-a-tag can be a user-error. Suggest that it may be a mistake with an advice message when creating such a tag. Those who do want to create a tag that point at another tag regularly can turn it off with the usual advice mechanism. Reported-by: Robert Dailey <> Helped-by: Jeff King <> Helped-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Denton Liu <> [jc: fixed test style and tweaked the log message] Signed-off-by: Junio C Hamano <>
2018-08-27Merge branch 'sg/test-must-be-empty'Junio C Hamano
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'SZEDER Gábor
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in '', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in ''. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in ''. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in ''. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-08-20Merge branch 'ab/test-must-be-empty-for-master'Junio C Hamano
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-07-30tests: make use of the test_must_be_empty functionÆvar Arnfjörð Bjarmason
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 <> Signed-off-by: Junio C Hamano <>
2018-07-20gpg-interface t: extend the existing GPG tests with GPGSMHenning Schild
Add test cases to cover the new X509/gpgsm support. Most of them resemble existing ones. They just switch the format to x509 and set the signingkey when creating signatures. Validation of signatures does not need any configuration of git, it does need gpgsm to be configured to trust the key(-chain). Several of the testcases build on top of existing gpg testcases. The commit ships a self-signed key for and configures gpgsm to trust it. Signed-off-by: Henning Schild <> Signed-off-by: Junio C Hamano <>
2018-05-23Merge branch 'nd/term-columns'Junio C Hamano
The code did not propagate the terminal width to subprocesses via COLUMNS environment variable, which it now does. This caused trouble to "git column" helper subprocess when "git tag --column=row" tried to list the existing tags on a display with non-default width. * nd/term-columns: column: fix off-by-one default width pager: set COLUMNS to term_columns()
2018-05-13column: fix off-by-one default widthNguyễn Thái Ngọc Duy
By default we want to fill the whole screen if possible, but we do not want to use up _all_ terminal columns because the last character is going hit the border, push the cursor over and wrap. Keep it at default value zero, which will make print_columns() set the width at term_columns() - 1. This affects the test in t7004 because effective column width before was 40 but now 39 so we need to compensate it by one or the output at 39 columns has a different layout. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-04-16gpg-interface: find the last gpg signature lineJeff King
A signed tag has a detached signature like this: object ... [...more header...] This is the tag body. -----BEGIN PGP SIGNATURE----- [opaque gpg data] -----END PGP SIGNATURE----- Our parser finds the _first_ line that appears to start a PGP signature block, meaning we may be confused by a signature (or a signature-like line) in the actual body. Let's keep parsing and always find the final block, which should be the detached signature over all of the preceding content. Signed-off-by: Jeff King <> Signed-off-by: Ben Toews <> Signed-off-by: Junio C Hamano <>
2018-04-16t7004: fix mistaken tag nameJeff King
We have a series of tests which create signed tags with various properties, but one test accidentally verifies a tag from much earlier in the series. Signed-off-by: Jeff King <> Signed-off-by: Ben Toews <> Signed-off-by: Junio C Hamano <>
2018-02-07tag: add --edit optionNicolas Morey-Chaisemartin
Add a --edit option whichs allows modifying the messages provided by -m or -F, the same way git commit --edit does. Signed-off-by: Nicolas Morey-Chaisemartin <> Signed-off-by: Junio C Hamano <>
2017-10-18Merge branch 'jk/ref-filter-colors-fix'Junio C Hamano
This is the "theoretically more correct" approach of simply stepping back to the state before plumbing commands started paying attention to "color.ui" configuration variable. Let's run with this one. * jk/ref-filter-colors-fix: tag: respect color.ui config Revert "color: check color.ui in git_default_config()" Revert "t6006: drop "always" color config tests" Revert "color: make "always" the same as "auto" in config"
2017-10-17tag: respect color.ui configJeff King
Since 11b087adfd (ref-filter: consult want_color() before emitting colors, 2017-07-13), we expect that setting "color.ui" to "always" will enable color tag formats even without a tty. As that commit was built on top of 136c8c8b8f (color: check color.ui in git_default_config(), 2017-07-13) from the same series, we didn't need to touch tag's config parsing at all. However, since we reverted 136c8c8b8f, we now need to explicitly call git_color_default_config() to make this work. Let's do so, and also restore the test dropped in 0c88bf5050 (provide --color option for all ref-filter users, 2017-10-03). That commit swapped out our "color.ui=always" test for "--color" in preparation for "always" going away. But since it is here to stay, we should test both cases. Note that for-each-ref also lost its color.ui support as part of reverting 136c8c8b8f. But as a plumbing command, it should _not_ respect the color.ui config. Since it also gained a --color option in 0c88bf5050, that's the correct way to ask it for color. We'll continue to test that, and confirm that "color.ui" is not respected. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-10-17Merge branch 'jk/ui-color-always-to-auto-maint' (early part) into ↵Junio C Hamano
jk/ref-filter-colors-fix-maint * 'jk/ui-color-always-to-auto-maint' (early part): color: make "always" the same as "auto" in config provide --color option for all ref-filter users t3205: use --color instead of color.branch=always t3203: drop "always" color test t6006: drop "always" color config tests t7502: use diff.noprefix for --verbose test t7508: use test_terminal for color output t3701: use test-terminal to collect color output t4015: prefer --color to -c color.diff=always test-terminal: set TERM=vt100
2017-10-04Merge branch 'jk/ui-color-always-to-auto-maint' into jk/ui-color-always-to-autoJunio C Hamano
* jk/ui-color-always-to-auto-maint: color: make "always" the same as "auto" in config provide --color option for all ref-filter users t3205: use --color instead of color.branch=always t3203: drop "always" color test t6006: drop "always" color config tests t7502: use diff.noprefix for --verbose test t7508: use test_terminal for color output t3701: use test-terminal to collect color output t4015: prefer --color to -c color.diff=always test-terminal: set TERM=vt100
2017-10-04provide --color option for all ref-filter usersJeff King
When ref-filter learned about want_color() in 11b087adfd (ref-filter: consult want_color() before emitting colors, 2017-07-13), it became useful to be able to turn colors off and on for specific commands. For git-branch, you can do so with --color/--no-color. But for git-for-each-ref and git-tag, the other users of ref-filter, you have no option except to tweak the "color.ui" config setting. Let's give both of these commands the usual color command-line options. This is a bit more obvious as a method for overriding the config. And it also prepares us for the behavior of "always" changing (so that we are still left with a way of forcing color when our output goes to a non-terminal). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-10-04test-terminal: set TERM=vt100Jeff King
The point of the test-terminal script is to simulate in the test scripts an environment where output is going to a real terminal. But since also sets TERM=dumb, the simulation isn't very realistic. The color code will skip auto-coloring for TERM=dumb, leading to us liberally sprinkling test_terminal env TERM=vt100 git ... through the test suite to convince the tests to actually generate colors. Let's set TERM for programs run under test_terminal, which is one less thing for test-writers to remember. In most cases the callers can be simplified, but note there is one interesting case in t4202. It uses test_terminal to check the auto-enabling of --decorate, but the expected output _doesn't_ contain colors (because TERM=dumb suppresses them). Using TERM=vt100 is closer to what the real world looks like; adjust the expected output to match. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-09-15test-lib: don't use ulimit in test prerequisites on cygwinRamsay Jones
On cygwin (and MinGW), the 'ulimit' built-in bash command does not have the desired effect of limiting the resources of new processes, at least for the stack and file descriptors. However, it always returns success and leads to several test prerequisites being erroneously set to true. Add a check for cygwin and MinGW to the prerequisite expressions, using a 'test_have_prereq !MINGW,!CYGWIN' clause, to guard against using ulimit. This affects the prerequisite expressions for the ULIMIT_STACK_SIZE, CMDLINE_LIMIT and ULIMIT_FILE_DESCRIPTORS prerequisites. Signed-off-by: Ramsay Jones <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-09-10Merge branch 'ab/ref-filter-no-contains' into maintJunio C Hamano
A test fix. * ab/ref-filter-no-contains: tests: don't give unportable ">" to "test" built-in, use -gt
2017-09-08t7004: move limited stack prereq to test-libMichael J Gruber
The lazy prerequisite ULIMIT_STACK_SIZE is used only in t7004 so far. Move it to so that it can be used in other tests (which it will be in a follow-up commit). Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2017-08-22Merge branch 'ab/ref-filter-no-contains'Junio C Hamano
A test fix. * ab/ref-filter-no-contains: tests: don't give unportable ">" to "test" built-in, use -gt
2017-08-07tests: don't give unportable ">" to "test" built-in, use -gtÆvar Arnfjörð Bjarmason
Change an argument to test_line_count (which'll ultimately be turned into a "test" expression) to use "-gt" instead of ">" for an arithmetic test. This broken on e.g. OpenBSD as of v2.13.0 with my commit ac3f5a3468 ("ref-filter: add --no-contains option to tag/branch/for-each-ref", 2017-03-24). Downstream just worked around it by patching git and didn't tell us about it, I discovered this when reading various Git packaging implementations: Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-07-13ref-filter: consult want_color() before emitting colorsJeff King
When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-05-11tests: fix tests broken under GETTEXT_POISON=YesPleaseÆvar Arnfjörð Bjarmason
The GETTEXT_POISON=YesPlease compile-time testing option added in my bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) has been slowly bitrotting as strings have been marked for translation, and new tests have been added without running it. I brought this up on the list ("[BUG] test suite broken with GETTEXT_POISON=YesPlease", [1]) asking whether this mode was useful at all anymore. At least one person occasionally uses it, and Lars Schneider offered to change one of the the Travis builds to run in this mode, so fix up the failing ones. My test setup runs most of the tests, with the notable exception of skipping all the p4 tests, so it's possible that there's still some lurking regressions I haven't fixed. 1. <> Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-04-11Merge branch 'ab/ref-filter-no-contains'Junio C Hamano
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-03-27Merge branch 'st/verify-tag'Junio C Hamano
A few unterminated here documents in tests were fixed, which in turn revealed incorrect expectations the tests make. These tests have been updated. * st/verify-tag: t7004, t7030: fix here-doc syntax errors
2017-03-24tag: add tests for --with and --withoutÆvar Arnfjörð Bjarmason
Change the test suite to test for these synonyms for --contains and --no-contains, respectively. Before this change there were no tests for them at all. This doesn't exhaustively test for them as well as their --contains and --no-contains synonyms, but at least it's something. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refÆvar Arnfjörð Bjarmason
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24tag: change --point-at to default to HEADÆvar Arnfjörð Bjarmason
Change the --points-at option to default to HEAD for consistency with its siblings --contains, --merged etc. which default to HEAD. Previously we'd get: $ git tag --points-at 2>&1 | head -n 1 error: option `points-at' requires a value This changes behavior added in commit ae7706b9ac (tag: add --points-at list option, 2012-02-08). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24tag: implicitly supply --list given another list-like optionÆvar Arnfjörð Bjarmason
Change the "tag" command to implicitly turn on its --list mode when provided with a list-like option such as --contains, --points-at etc. This is for consistency with how "branch" works. When "branch" is given a list-like option, such as --contains, it implicitly provides --list. Before this change "tag" would error out on those sorts of invocations. I.e. while both of these worked for "branch": git branch --contains v2.8.0 <pattern> git branch --list --contains v2.8.0 <pattern> Only the latter form worked for "tag": git tag --contains v2.8.0 '*rc*' git tag --list --contains v2.8.0 '*rc*' Now "tag", like "branch", will implicitly supply --list when a list-like option is provided, and no other conflicting non-list options (such as -d) are present on the command-line. Spelunking through the history via: git log --reverse -p -G'only allowed with' -- '*builtin*tag*c' Reveals that there was no good reason for not allowing this in the first place. The --contains option added in 32c35cfb1e ("git-tag: Add --contains option", 2009-01-26) made this an error. All the other subsequent list-like options that were added copied its pattern of making this usage an error. The only tests that break as a result of this change are tests that were explicitly checking that this "branch-like" usage wasn't permitted. Change those failing tests to check that this invocation mode is permitted, add extra tests for the list-like options we weren't testing, and tests to ensure that e.g. we don't toggle the list mode in the presence of other conflicting non-list options. With this change errors messages such as "--contains option is only allowed with -l" don't make sense anymore, since options like --contain turn on -l. Instead we error out when list-like options such as --contain are used in conjunction with conflicting options such as -d or -v. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24tag: change misleading --list <pattern> documentationÆvar Arnfjörð Bjarmason
Change the documentation for --list so that it's described as a toggle, not as an option that takes a <pattern> as an argument. Junio initially documented this in b867c7c23a ("git-tag: -l to list tags (usability).", 2006-02-17), but later Jeff King changed "tag" to accept multiple patterns in 588d0e834b ("tag: accept multiple patterns for --list", 2011-06-20). However, documenting this as "-l <pattern>" was never correct, as these both worked before Jeff's change: git tag -l 'v*' git tag 'v*' -l One would expect an option that was documented like that to only accept: git tag --list git tag --list 'v*rc*' And after Jeff's change, one that took multiple patterns: git tag --list 'v*rc*' --list '*2.8*' But since it's actually a toggle all of these work as well, and produce identical output to the last example above: git tag --list 'v*rc*' '*2.8*' git tag --list 'v*rc*' '*2.8*' --list --list --list git tag --list 'v*rc*' '*2.8*' --list -l --list -l --list Now the documentation is more in tune with how the "branch" command describes its --list option since commit cddd127b9a ("branch: introduce --list option", 2011-08-28). Change the test suite to assert that these invocations work for the cases that weren't already being tested for. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24tag: add more incompatibles mode testsÆvar Arnfjörð Bjarmason
Amend the test suite to test for more invalid uses like "-l -a" etc. This change tests the code path in builtin/tag.c between lines: if (argc == 0 && !cmdmode) And: if ((create_tag_object || force) && (cmdmode != 0)) Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24t7004, t7030: fix here-doc syntax errorsSantiago Torres
Jan Palus noticed that some here-doc are spelled incorrectly, resulting the entire remainder of the test snippet being slurped into the "expect" file as if it were data, e.g. in this sequence cat >expect <<EOF && ... expectation ... EOF git $cmd_being_tested >actual && test_cmp expect actual the last command of the test is "cat" that sends everything to 'expect' and succeeds. Fixing these issues in t7004 and t7030 reveals that "git tag -v" and "git verify-tag" with their --format option do not work as the test was expecting originally. Instead of showing both valid tags and tags with incorrect signatures on their output, tags that do not pass verification are omitted from the output. Another breakage that is uncovered is that these tests must be restricted to environment where gpg is available. Arguably, that is a safer behaviour, and because the format specifiers like %(tag) do not have a way to show if the signature verifies correctly, the command with the --format option cannot be used to get a list of tags annotated with their signature validity anyway. For now, let's fix the here-doc syntax, update the expectation to match the reality, and update the test prerequisite. Maybe later when we extend the --format language available to "git tag -v" and "git verify-tag" to include things like "%(gpg:status)", we may want to change the behaviour so that piping a list of tag names into xargs git verify-tag --format='%(gpg:status) %(tag)' becomes a good way to produce such a list, but that is a separate topic. Noticed-by: Jan Palus <> Helped-by: Jeff King <> Signed-off-by: Santiago Torres <> Signed-off-by: Junio C Hamano <>
2017-03-23tag tests: fix a typo in a test descriptionÆvar Arnfjörð Bjarmason
Change "suceed" to "succeed" in a test description. The typo has been here since the code was originally added in commit ef5a6fb597 ("Add test-script for git-tag", 2007-06-28). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>