summaryrefslogtreecommitdiff
path: root/t/t7006-pager.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-08-01log: flip the --mailmap default unconditionallyLibravatar Junio C Hamano1-2/+0
It turns out that being cautious to warn against upcoming default change was an unpopular behaviour, and such a care can easily be defeated by distro packagers to render it ineffective anyway. Just flip the default, with only a mention in the release notes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-15tests: defang pager tests by explicitly disabling the log.mailmap warningLibravatar Ariadne Conill1-0/+2
In the previous patch, we added a deprecation warning for the current log.mailmap setting. This warning only appears when git is attached to a controlling terminal. Some tests however run under an emulated terminal, so we need to disable the warning for those tests. Thanks to Junio for suggesting that we do this in the setup function. Signed-off-by: Ariadne Conill <ariadne@dereferenced.org> 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-2/+1
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>
2018-02-21config: change default of `pager.config` to "on"Libravatar Martin Ågren1-6/+6
This is similar to ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) and is safe now that we do not consider `pager.config` at all when we are not listing or getting configuration. This change will help with listing large configurations, but will not hurt users of `git config --edit` as it would have before the previous commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21config: respect `pager.config` in list/get-mode onlyLibravatar Martin Ågren1-5/+5
Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect `pager.config` when we are listing or "get"ing config. We have several getters and some are guaranteed to give at most one line of output. Paging all getters including those could be convenient from a documentation point-of-view. The downside would be that a misconfigured or not so modern pager might wait for user interaction before terminating. Let's instead respect the config for precisely those getters which may produce more than one line of output. `--get-urlmatch` may or may not produce multiple lines of output, depending on the exact usage. Let's not try to recognize the two modes, but instead make `--get-urlmatch` always respect the config. Analyzing the detailed usage might be trivial enough here, but could establish a precedent that we will never be able to enforce throughout the codebase and that will just open a can of worms. This fixes the failing test added in the previous commit. Also adapt the test for whether `git config foo.bar bar` and `git config --get foo.bar` respects `pager.config`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21t7006: add tests for how git config paginatesLibravatar Martin Ågren1-7/+42
The next couple of commits will change how `git config` handles `pager.config`, similar to how de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02) and ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) changed `git tag`. Similar work has also been done to `git branch`. Add tests in this area to make sure that we don't regress and so that the upcoming commits can be made clearer by adapting the tests. Add tests for simple config-setting, `--edit`, `--get`, `--get-urlmatch`, `get-all`, and `--list`. Those represent a fair portion of the various options that will be affected by the next two commits. Use `test_expect_failure` to document that we currently respect the pager-configuration with `--edit`. The current behavior is buggy since the pager interferes with the editor and makes the end result completely broken. See also b3ee740c8 (t7006: add tests for how git tag paginates, 2017-08-02). The next commit will teach simple config-setting and `--get` to ignore `pager.config`. Test the current behavior as "success", not "failure", since the currently expected behavior according to documentation would be to page. The next commit will change that expectation by updating the documentation on `git config` and will redefine those successful tests. Remove the test added in commit 3ba7e6e29a (config: run setup_git_directory_gently() sooner, 2010-08-05) since it has some overlap with these. We could leave it or tweak it, or place new tests like these next to it, but let's instead make the tests for `git config` as similar as possible to the ones for `git tag` and `git branch`, and place them after those. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-28Merge branch 'ma/branch-list-paginate'Libravatar Junio C Hamano1-0/+38
"git branch --list" learned to show its output through the pager by default when the output is going to a terminal, which is controlled by the pager.branch configuration variable. This is similar to a recent change to "git tag --list". * ma/branch-list-paginate: branch: change default of `pager.branch` to "on" branch: respect `pager.branch` in list-mode only t7006: add tests for how git branch paginates
2017-11-20branch: change default of `pager.branch` to "on"Libravatar Martin Ågren1-5/+5
This is similar to ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) and is safe now that we do not consider `pager.branch` at all when we are not listing branches. This change will help with listing many branches, but will not hurt users of `git branch --edit-description` as it would have before the previous commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-20branch: respect `pager.branch` in list-mode onlyLibravatar Martin Ågren1-3/+3
Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect `pager.branch` when we are listing branches. We have two possibilities of generalizing what that earlier commit made to `git tag`. One is to interpret, e.g., --set-upstream-to as "it does not use an editor, so we should page". Another, the one taken by this commit, is to say "it does not list, so let's not page". That is in line with the approach of the series on `pager.tag` and in particular the wording in Documentation/git-tag.txt, which this commit reuses for git-branch.txt. This fixes the failing test added in the previous commit. Also adapt the test for whether `git branch --set-upstream-to` respects `pager.branch`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-20t7006: add tests for how git branch paginatesLibravatar Martin Ågren1-0/+38
The next couple of commits will change how `git branch` handles `pager.branch`, similar to how de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02) and ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) changed `git tag`. Add tests in this area to make sure that we don't regress and so that the upcoming commits can be made clearer by adapting the tests. Add some tests for `--list` (implied), one for `--edit-description`, and one for `--set-upstream-to` as a representative of "something other than the first two". In particular, use `test_expect_failure` to document that we currently respect the pager-configuration with `--edit-description`. The current behavior is buggy since the pager interferes with the editor and makes the end result completely broken. See also b3ee740c8 (t7006: add tests for how git tag paginates, 2017-08-02). Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06Merge branch 'kd/auto-col-with-pager-fix'Libravatar Junio C Hamano1-0/+14
"auto" as a value for the columnar output configuration ought to judge "is the output consumed by humans?" with the same criteria as "auto" for coloured output configuration, i.e. either the standard output stream is going to tty, or a pager is in use. We forgot the latter, which has been fixed. * kd/auto-col-with-pager-fix: column: do not include pager.c column: show auto columns when pager is active
2017-10-17column: show auto columns when pager is activeLibravatar Kevin Daudt1-0/+14
When columns are set to automatic for git tag and the output is paginated by git, the output is a single column instead of multiple columns. Standard behaviour in git is to honor auto values when the pager is active, which happens for example with commands like git log showing colors when being paged. Since ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02), the pager has been enabled by default, exposing this problem to more people. finalize_colopts in column.c only checks whether the output is a TTY to determine if columns should be enabled with columns set to auto. Also check if the pager is active. Adding a test for git column is possible but requires some care to work around a race on stdin. See commit 18d8c2693 (test_terminal: redirect child process' stdin to a pty, 2015-08-04). Test git tag instead, since that does not involve stdin, and since that was the original motivation for this patch. Helped-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04Merge branch 'jk/ui-color-always-to-auto-maint' into jk/ui-color-always-to-autoLibravatar Junio C Hamano1-3/+3
* 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-04test-terminal: set TERM=vt100Libravatar Jeff King1-3/+3
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 test-lib.sh 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03git.c: ignore pager.* when launching builtin as dashed externalLibravatar Martin Ågren1-1/+1
When running, e.g., `git -c alias.bar=foo bar`, we expand the alias and execute `git-foo` as a dashed external. This is true even if git foo is a builtin. That is on purpose, and is motivated in a comment which was added in commit 441981bc ("git: simplify environment save/restore logic", 2016-01-26). Shortly before we launch a dashed external, and unless we have already found out whether we should use a pager, we check `pager.foo`. This was added in commit 92058e4d ("support pager.* for external commands", 2011-08-18). If the dashed external is a builtin, this does not match that commit's intention and is arguably wrong, since it would be cleaner if we let the "dashed external builtin" handle `pager.foo`. This has not mattered in practice, but a recent patch taught `git-tag` to ignore `pager.tag` under certain circumstances. But, when started using an alias, it doesn't get the chance to do so, as outlined above. That recent patch added a test to document this breakage. Do not check `pager.foo` before launching a builtin as a dashed external, i.e., if we recognize the name of the external as a builtin. Change the test to use `test_expect_success`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03tag: change default of `pager.tag` to "on"Libravatar Martin Ågren1-14/+14
The previous patch taught `git tag` to only respect `pager.tag` in list-mode. That patch left the default value of `pager.tag` at "off". After that patch, it makes sense to let the default value be "on" instead, since it will help with listing many tags, but will not hurt users of `git tag -a` as it would have before. Make that change. Update documentation and tests. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03tag: respect `pager.tag` in list-mode onlyLibravatar Martin Ågren1-1/+14
Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. Someone who makes use of both `git tag -a` and `git tag -l` will probably not set `pager.tag`, so that `git tag -a` will actually work, at the cost of not paging output of `git tag -l`. Use the mechanisms introduced in two earlier patches to ignore `pager.tag` in git.c and let the `git tag` builtin handle it on its own. Only respect `pager.tag` when running in list-mode. There is a window between where the pager is started before and after this patch. This means that early errors can behave slightly different before and after this patch. Since operation-parsing has to happen inside this window, this can be seen with `git -c pager.tag="echo pager is used" tag -l --unknown-option`. This change in paging-behavior should be acceptable since it only affects erroneous usages. Update the documentation and update tests. If an alias is used to run `git tag -a`, then `pager.tag` will still be respected. Document this known breakage. It will be fixed in a later commit. Add a similar test for `-l`, which works. Noticed-by: Anatoly Borodin <anatoly.borodin@gmail.com> Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03t7006: add tests for how git tag paginatesLibravatar Martin Ågren1-0/+67
Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. Someone who makes use of both `git tag -a` and `git tag -l` will probably not set `pager.tag`, so that `git tag -a` will actually work, at the cost of not paging output of `git tag -l`. Since we're about to change how `git tag` respects `pager.tag`, add tests around this, including how the configuration is ignored if --no-pager or --paginate are used. Construct tests with a few different subcommands. First, use -l. Second, use "no arguments" and --contains, since those imply -l. (There are more arguments which imply -l, but using these two should be enough.) Third, use -a as a representative for "not -l". Actually, the tests use `git tag -am` so no editor is launched, but that is irrelevant, since we just want to see whether the pager is used or not. Make one of the tests demonstrate the broken behavior mentioned above, where `git tag -a` respects `pager.tag`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15alias: use the early config machinery to expand aliasesLibravatar Johannes Schindelin1-1/+1
Instead of discovering the .git/ directory, reading the config and then trying to painstakingly reset all the global state if we did not find a matching alias, let's use the early config machinery instead. It may look like unnecessary work to discover the .git/ directory in the early config machinery and then call setup_git_directory_gently() in the case of a shell alias, repeating the very same discovery *again*. However, we have to do this as the early config machinery takes pains *not* to touch any global state, while shell aliases expect a possibly changed working directory and at least the GIT_PREFIX and GIT_DIR variables to be set. This change also fixes a known issue where Git tried to read the pager config from an incorrect path in a subdirectory of a Git worktree if an alias expanded to a shell command. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15t7006: demonstrate a problem with aliases in subdirectoriesLibravatar Johannes Schindelin1-0/+11
When expanding aliases, the git_dir is set during the alias expansion (by virtue of running setup_git_directory_gently()). This git_dir may be relative to the current working directory, and indeed often is simply ".git/". When the alias expands to a shell command, we restore the original working directory, though, yet we do not reset git_dir. As a consequence, subsequent read_early_config() runs will mistake the git_dir to be populated properly and not find the correct config. Demonstrate this problem by adding a test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-14read_early_config(): really discover .git/Libravatar Johannes Schindelin1-4/+4
Earlier, we punted and simply assumed that we are in the top-level directory of the project, and that there is no .git file but a .git/ directory so that we can read directly from .git/config. However, that is not necessarily true. We may be in a subdirectory. Or .git may be a gitfile. Or the environment variable GIT_DIR may be set. To remedy this situation, we just refactored the way setup_git_directory() discovers the .git/ directory, to make it reusable, and more importantly, to leave all global variables and the current working directory alone. Let's discover the .git/ directory correctly in read_early_config() by using that new function. This fixes 4 known breakages in t7006. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-03t7006: replace dubious testLibravatar Johannes Schindelin1-1/+11
The idea of the test case "git -p - core.pager is not used from subdirectory" was to verify that the setup_git_directory() function had not been called just to obtain the core.pager setting. However, we are about to fix the early config machinery so that it *does* work, without messing up the global state. Once that is done, the core.pager setting *will* be used, even when running from a subdirectory, and that is a Good Thing. The intention of that test case, however, was to verify that the setup_git_directory() function has not run, because it changes global state such as the current working directory. To keep that spirit, but fix the incorrect assumption, this patch replaces that test case by a new one that verifies that the pager is run in the subdirectory, i.e. that the current working directory has not been changed at the time the pager is configured and launched, even if the `rev-parse` command requires a .git/ directory and *will* change the working directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-04pager: move pager-specific setup into the buildLibravatar Eric Wong1-0/+13
Allowing PAGER_ENV to be set at build-time allows us to move pager-specific knowledge out of our build. This allows us to set a better default for FreeBSD more(1), which pretends not to understand ANSI color escapes if the MORE environment variable is left empty, but accepts the same variables as less(1) Originally-from: https://public-inbox.org/git/xmqq61piw4yf.fsf@gitster.dls.corp.google.com/ Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-07t/t7006-pager.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-1/+1
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31Merge branch 'jk/fix-alias-pager-config-key-warnings'Libravatar Junio C Hamano1-0/+9
Because the configuration system does not allow "alias.0foo" and "pager.0foo" as the configuration key, the user cannot use '0foo' as a custom command name anyway, but "git 0foo" tried to look these keys up and emitted useless warnings before saying '0foo is not a git command'. These warning messages have been squelched. * jk/fix-alias-pager-config-key-warnings: config: silence warnings for command names with invalid keys
2015-08-24config: silence warnings for command names with invalid keysLibravatar Jeff King1-0/+9
When we are running the git command "foo", we may have to look up the config keys "pager.foo" and "alias.foo". These config schemes are mis-designed, as the command names can be anything, but the config syntax has some restrictions. For example: $ git foo_bar error: invalid key: pager.foo_bar error: invalid key: alias.foo_bar git: 'foo_bar' is not a git command. See 'git --help'. You cannot name an alias with an underscore. And if you have an external command with one, you cannot configure its pager. In the long run, we may develop a different config scheme for these features. But in the near term (and because we'll need to support the existing scheme indefinitely), we should at least squelch the error messages shown above. These errors come from git_config_parse_key. Ideally we would pass a "quiet" flag to the config machinery, but there are many layers between the pager code and the key parsing. Passing a flag through all of those would be an invasive change. Instead, let's provide a config function to report on whether a key is syntactically valid, and have the pager and alias code skip lookup for bogus keys. We can build this easily around the existing git_config_parse_key, with two minor modifications: 1. We now handle a NULL store_key, to validate but not write out the normalized key. 2. We accept a "quiet" flag to avoid writing to stderr. This doesn't need to be a full-blown public "flags" field, because we can make the existing implementation a static helper function, keeping the mess contained inside config.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-19tests: use "env" to run commands with temporary env-var settingsLibravatar David Tran1-15/+3
Ordinarily, we would say "VAR=VAL command" to execute a tested command with environment variable(s) set only for that command. This however does not work if 'command' is a shell function (most notably 'test_must_fail'); the result of the assignment is retained and affects later commands. To avoid this, we used to assign and export environment variables and run such a test in a subshell, like so: ( VAR=VAL && export VAR && test_must_fail git command to be tested ) But with "env" utility, we should be able to say: test_must_fail env VAR=VAL git command to be tested which is much shorter and easier to read. Signed-off-by: David Tran <unsignedzero@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-31pager test: make fake pager consume all its inputLibravatar Jonathan Nieder1-1/+1
Otherwise there is a race: if 'git log' finishes writing before the pager terminates and closes the pipe, all is well, and if the pager finishes quickly enough then 'git log' terminates with SIGPIPE. died of signal 13 at /build/buildd/git-1.9~rc1/t/test-terminal.perl line 33. not ok 6 - LESS and LV envvars are set for pagination Noticed on Ubuntu PPA builders, where the race was lost about half the time. Compare v1.7.0.2~6^2 (tests: Fix race condition in t7006-pager, 2010-02-22). Reported-by: Anders Kaseorg <andersk@MIT.EDU> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07pager: set LV=-c alongside LESS=FRSXLibravatar Jonathan Nieder1-0/+12
On systems with lv configured as the preferred pager (i.e., DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the environment) git commands that use color show control codes instead of color in the pager: $ git diff ^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m ^[[1mindex aa4f0b2..17e113e 100644^[[m ^[[1m--- a/.mailfilter^[[m ^[[1m+++ b/.mailfilter^[[m ^[[36m@@ -1,11 +1,58 @@^[[m "less" avoids this problem because git uses the LESS environment variable to pass the -R option ('output ANSI color escapes in raw form') by default. Use the LV environment variable to pass 'lv' the -c option ('allow ANSI escape sequences for text decoration / color') to fix it for lv, too. Noticed when the default value for color.ui flipped to 'auto' in v1.8.4-rc0~36^2~1 (2013-06-10). Reported-by: Olaf Meeuwissen <olaf.meeuwissen@avasys.jp> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-14test: errors preparing for a test are not specialLibravatar Jonathan Nieder1-56/+17
This script uses the following idiom to start each test in a known good state: test_expect_success 'some commands use a pager' ' rm -f paginated.out || cleanup_fail && test_terminal git log && test -e paginated.out ' where "cleanup_fail" is a function that prints an error message and errors out. That is bogus on three levels: - Cleanup commands like "rm -f" and "test_unconfig" are designed not to fail, so this logic would never trip. - If they were to malfunction anyway, it is not useful to set apart cleanup commands as a special kind of failure with a special error message. Whichever command fails, the next step is to investigate which command that was, for example by running tests with "prove -e 'sh -x'", and fix it. - Relying on left-associativity of mixed &&/|| lists makes the code somewhat cryptic. The fix is simple: drop the "|| cleanup_fail" in each test and the definition of the "cleanup_fail" function so no new callers can arise. Reported-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-19support pager.* for external commandsLibravatar Jeff King1-0/+36
Without this patch, any commands that are not builtin would not respect pager.* config. For example: git config pager.stash false git stash list would still use a pager. With this patch, pager.stash now has an effect. If it is not specified, we will still fall back to pager.log when we invoke "log" from "stash list". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-19color: delay auto-color decision until point of useLibravatar Jeff King1-0/+12
When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18setup_pager: set GIT_PAGER_IN_USELibravatar Jeff King1-0/+11
We have always set a global "spawned_pager" variable when we start the pager. This lets us make the auto-color decision later in the program as as "we are outputting to a terminal, or to a pager which can handle colors". Commit 6e9af86 added support for the GIT_PAGER_IN_USE environment variable. An external program calling git (e.g., git-svn) could set this variable to indicate that it had already started the pager, and that the decision about auto-coloring should take that into account. However, 6e9af86 failed to do the reverse, which is to tell external programs when git itself has started the pager. Thus a git command implemented as an external script that has the pager turned on (e.g., "git -p stash show") would not realize it was going to a pager, and would suppress colors. This patch remedies that; we always set GIT_PAGER_IN_USE when we start the pager, and the value is respected by both this program and any spawned children. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18t7006: use test_config helpersLibravatar Jeff King1-21/+18
In some cases, this is just making the test script a little shorter and easier to read. However, there are several places where we didn't take proper precautions against polluting downstream tests with our config; this fixes them, too. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18t7006: modernize calls to unsetLibravatar Jeff King1-2/+2
These tests break &&-chaining to deal with broken "unset" implementations. Instead, they should just use sane_unset. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-08Merge branch 'jk/pager-per-command'Libravatar Junio C Hamano1-0/+29
* jk/pager-per-command: allow command-specific pagers in pager.<cmd>
2010-11-24Merge branch 'en/and-cascade-tests'Libravatar Junio C Hamano1-5/+5
* en/and-cascade-tests: (25 commits) t4124 (apply --whitespace): use test_might_fail t3404: do not use 'describe' to implement test_cmp_rev t3404 (rebase -i): introduce helper to check position of HEAD t3404 (rebase -i): move comment to description t3404 (rebase -i): unroll test_commit loops t3301 (notes): use test_expect_code for clarity t1400 (update-ref): use test_must_fail t1502 (rev-parse --parseopt): test exit code from "-h" t6022 (renaming merge): chain test commands with && test-lib: introduce test_line_count to measure files tests: add missing &&, batch 2 tests: add missing && Introduce sane_unset and use it to ensure proper && chaining t7800 (difftool): add missing && t7601 (merge-pull-config): add missing && t7001 (mv): add missing && t6016 (rev-list-graph-simplify-history): add missing && t5602 (clone-remote-exec): add missing && t4026 (color): remove unneeded and unchained command t4019 (diff-wserror): add lots of missing && ... Conflicts: t/t7006-pager.sh
2010-11-17allow command-specific pagers in pager.<cmd>Libravatar Jeff King1-0/+29
A user may want different pager settings or even a different pager for various subcommands (e.g., because they use different less settings for "log" vs "diff", or because they have a pager that interprets only log output but not other commands). This patch extends the pager.<cmd> syntax to support not only boolean to-page-or-not-to-page, but also to specify a pager just for a specific command. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-18test_terminal: catch use without TTY prerequisiteLibravatar Jonathan Nieder1-6/+1
It is easy to forget to declare the TTY prerequisite when writing tests on a system where it would always be satisfied (because IO::Pty is installed; see v1.7.3-rc0~33^2, 2010-08-16 for example). Automatically detect this problem so there is no need to remember. test_terminal: need to declare TTY prerequisite test_must_fail: command not found: test_terminal echo hi test_terminal returns status 127 in this case to simulate not being available. Also replace the SIMPLEPAGERTTY prerequisite on one test with "SIMPLEPAGER,TTY", since (1) the latter is supported now and (2) the prerequisite detection relies on the TTY prereq being explicitly declared. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-18tests: factor out terminal handling from t7006Libravatar Jeff King1-30/+1
Other tests besides the pager ones may want to check how we handle output to a terminal. This patch makes the code reusable. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06Introduce sane_unset and use it to ensure proper && chainingLibravatar Elijah Newren1-5/+5
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-16t7006 (pager): add missing TTY prerequisitesLibravatar Jonathan Nieder1-2/+2
The "git bundle unbundle" and "git config" pagination tests are not supposed to run when stdout is not a terminal and IO::Pty not available to make one on the fly. Reported-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15config: run setup_git_directory_gently() soonerLibravatar Nguyễn Thái Ngọc Duy1-0/+8
For the pager choice (and the choice to paginate) to reflect the current repository configuration, the repository needs to be located first. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15bundle: run setup_git_directory_gently() soonerLibravatar Nguyễn Thái Ngọc Duy1-0/+33
Without this change, “git -p bundle” does not always respect the repository-local “[core] pager” setting. It is hard to notice because subcommands other than “git bundle unbundle” do not produce much output. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15apply: run setup_git_directory_gently() soonerLibravatar Nguyễn Thái Ngọc Duy1-0/+3
As v1.7.2~16^2 (2010-07-14) explains, without this change, “git --paginate apply” can ignore the repository-local “[core] pager” configuration. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11grep: run setup_git_directory_gently() soonerLibravatar Nguyễn Thái Ngọc Duy1-0/+13
git grep already runs a repository search unconditionally, even when the --no-index option is supplied; running such a search earlier is not very risky. Just like with shortlog, without this change, the “[pager] grep” configuration is not respected at all. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11shortlog: run setup_git_directory_gently() soonerLibravatar Nguyễn Thái Ngọc Duy1-0/+9
shortlog already runs a repository search unconditionally; running such a search earlier is not very risky. Without this change, the “[pager] shortlog” configuration is not respected at all: “git shortlog” unconditionally paginates. The tests are a bit slow. Running the full battery like this for all built-in commands would be counterproductive; the intent is rather to test shortlog as a representative example command using ..._gently(). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-15Merge branch 'jn/paginate-fix'Libravatar Junio C Hamano1-45/+196
* jn/paginate-fix: git --paginate: paginate external commands again git --paginate: do not commit pager choice too early tests: local config file should be honored from subdirs of toplevel t7006: test pager configuration for several git commands t7006 (pager): introduce helper for parameterized tests Conflicts: t/t7006-pager.sh
2010-07-14git --paginate: paginate external commands againLibravatar Jonathan Nieder1-12/+35
73e25e7c (git --paginate: do not commit pager choice too early, 2010-06-26) failed to take some cases into account. 1b. Builtins that do not use RUN_SETUP (like git config) do not find GIT_DIR set correctly when the pager is launched from run_builtin(). So the core.pager configuration is not honored from subdirectories of the toplevel for them. 4a. External git commands (like git request-pull) relied on the early pager launch to take care of handling the -p option. Ever since 73e25e7c, they do not honor the -p option at all. 4b. Commands invoked through ! aliases (like ls) were also relying on the early pager launch. Fix (4a) by launching the pager (if requested) before running such a “dashed external”. For simplicity, this still does not search for a .git directory before running the external command; when run from a subdirectory of the toplevel, therefore, the “[core] pager” configuration is still not honored. Fix (4b) by launching pager if requested before carrying out such an alias. Actually doing this has no effect, since the pager (if any) would have already been launched in a failed attempt to try a dashed external first. The choice-of-pager-not-honored-from- subdirectory bug still applies here, too. (1b) is not a regression. There is no need to fix it yet. Noticed by Junio. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>