1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-31 22:37:54 +01:00
git/t/t7006-pager.sh

483 lines
12 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='Test automatic use of a pager.'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-pager.sh
. "$TEST_DIRECTORY"/lib-terminal.sh
test_expect_success 'setup' '
sane_unset GIT_PAGER GIT_PAGER_IN_USE &&
test_unconfig core.pager &&
PAGER="cat >paginated.out" &&
export PAGER &&
test_commit initial
'
test_expect_success TTY 'some commands use a pager' '
rm -f paginated.out &&
test_terminal git log &&
test -e paginated.out
'
test_expect_failure TTY 'pager runs from subdir' '
echo subdir/paginated.out >expected &&
mkdir -p subdir &&
rm -f paginated.out subdir/paginated.out &&
(
cd subdir &&
test_terminal git log
) &&
{
ls paginated.out subdir/paginated.out ||
:
} >actual &&
test_cmp expected actual
'
test_expect_success TTY 'LESS and LV envvars are set for pagination' '
(
sane_unset LESS LV &&
PAGER="env >pager-env.out; wc" &&
export PAGER &&
test_terminal git log
) &&
grep ^LESS= pager-env.out &&
grep ^LV= pager-env.out
'
test_expect_success !MINGW,TTY 'LESS and LV envvars set by git-sh-setup' '
(
sane_unset LESS LV &&
PAGER="env >pager-env.out; wc" &&
export PAGER &&
PATH="$(git --exec-path):$PATH" &&
export PATH &&
test_terminal sh -c ". git-sh-setup && git_pager"
) &&
grep ^LESS= pager-env.out &&
grep ^LV= pager-env.out
'
test_expect_success TTY 'some commands do not use a pager' '
rm -f paginated.out &&
test_terminal git rev-list HEAD &&
! test -e paginated.out
'
test_expect_success 'no pager when stdout is a pipe' '
rm -f paginated.out &&
git log | cat &&
! test -e paginated.out
'
test_expect_success 'no pager when stdout is a regular file' '
rm -f paginated.out &&
git log >file &&
! test -e paginated.out
'
test_expect_success TTY 'git --paginate rev-list uses a pager' '
rm -f paginated.out &&
test_terminal git --paginate rev-list HEAD &&
test -e paginated.out
'
test_expect_success 'no pager even with --paginate when stdout is a pipe' '
rm -f file paginated.out &&
git --paginate log | cat &&
! test -e paginated.out
'
test_expect_success TTY 'no pager with --no-pager' '
rm -f paginated.out &&
test_terminal git --no-pager log &&
! test -e paginated.out
'
test_expect_success TTY 'configuration can disable pager' '
rm -f paginated.out &&
test_unconfig pager.grep &&
test_terminal git grep initial &&
test -e paginated.out &&
rm -f paginated.out &&
test_config pager.grep false &&
test_terminal git grep initial &&
! test -e paginated.out
'
test_expect_success TTY 'git config uses a pager if configured to' '
rm -f paginated.out &&
test_config pager.config true &&
test_terminal git config --list &&
test -e paginated.out
'
test_expect_success TTY 'configuration can enable pager (from subdir)' '
rm -f paginated.out &&
mkdir -p subdir &&
test_config pager.bundle true &&
git bundle create test.bundle --all &&
rm -f paginated.out subdir/paginated.out &&
(
cd subdir &&
test_terminal git bundle unbundle ../test.bundle
) &&
{
test -e paginated.out ||
test -e subdir/paginated.out
}
'
# A colored commit log will begin with an appropriate ANSI escape
# for the first color; the text "commit" comes later.
colorful() {
read firstline <$1
! expr "$firstline" : "[a-zA-Z]" >/dev/null
}
test_expect_success 'tests can detect color' '
rm -f colorful.log colorless.log &&
git log --no-color >colorless.log &&
git log --color >colorful.log &&
! colorful colorless.log &&
colorful colorful.log
'
test_expect_success 'no color when stdout is a regular file' '
rm -f colorless.log &&
test_config color.ui auto &&
git log >colorless.log &&
! colorful colorless.log
'
test_expect_success TTY 'color when writing to a pager' '
rm -f paginated.out &&
test_config color.ui auto &&
test_terminal env TERM=vt100 git log &&
colorful paginated.out
'
color: delay auto-color decision until point of use 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-18 07:04:23 +02:00
test_expect_success TTY 'colors are suppressed by color.pager' '
rm -f paginated.out &&
test_config color.ui auto &&
test_config color.pager false &&
test_terminal env TERM=vt100 git log &&
color: delay auto-color decision until point of use 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-18 07:04:23 +02:00
! colorful paginated.out
'
test_expect_success 'color when writing to a file intended for a pager' '
rm -f colorful.log &&
test_config color.ui auto &&
(
TERM=vt100 &&
GIT_PAGER_IN_USE=true &&
export TERM GIT_PAGER_IN_USE &&
git log >colorful.log
) &&
colorful colorful.log
'
test_expect_success TTY 'colors are sent to pager for external commands' '
test_config alias.externallog "!git log" &&
test_config color.ui auto &&
test_terminal env TERM=vt100 git -p externallog &&
colorful paginated.out
'
# Use this helper to make it easy for the caller of your
# terminal-using function to specify whether it should fail.
# If you write
#
# your_test() {
# parse_args "$@"
#
# $test_expectation "$cmd - behaves well" "
# ...
# $full_command &&
# ...
# "
# }
#
# then your test can be used like this:
#
# your_test expect_(success|failure) [test_must_fail] 'git foo'
#
parse_args() {
test_expectation="test_$1"
shift
if test "$1" = test_must_fail
then
full_command="test_must_fail test_terminal "
shift
else
full_command="test_terminal "
fi
cmd=$1
full_command="$full_command $1"
}
test_default_pager() {
parse_args "$@"
$test_expectation SIMPLEPAGER,TTY "$cmd - default pager is used by default" "
sane_unset PAGER GIT_PAGER &&
test_unconfig core.pager &&
rm -f default_pager_used &&
cat >\$less <<-\EOF &&
#!/bin/sh
wc >default_pager_used
EOF
chmod +x \$less &&
(
PATH=.:\$PATH &&
export PATH &&
$full_command
) &&
test -e default_pager_used
"
}
test_PAGER_overrides() {
parse_args "$@"
$test_expectation TTY "$cmd - PAGER overrides default pager" "
sane_unset GIT_PAGER &&
test_unconfig core.pager &&
rm -f PAGER_used &&
PAGER='wc >PAGER_used' &&
export PAGER &&
$full_command &&
test -e PAGER_used
"
}
test_core_pager_overrides() {
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
if_local_config=
used_if_wanted='overrides PAGER'
test_core_pager "$@"
}
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
test_local_config_ignored() {
if_local_config='! '
used_if_wanted='is not used'
test_core_pager "$@"
}
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
test_core_pager() {
parse_args "$@"
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
$test_expectation TTY "$cmd - repository-local core.pager setting $used_if_wanted" "
sane_unset GIT_PAGER &&
rm -f core.pager_used &&
PAGER=wc &&
export PAGER &&
test_config core.pager 'wc >core.pager_used' &&
$full_command &&
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
${if_local_config}test -e core.pager_used
"
}
test_core_pager_subdir() {
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
if_local_config=
used_if_wanted='overrides PAGER'
test_pager_subdir_helper "$@"
}
test_no_local_config_subdir() {
if_local_config='! '
used_if_wanted='is not used'
test_pager_subdir_helper "$@"
}
test_pager_subdir_helper() {
parse_args "$@"
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
$test_expectation TTY "$cmd - core.pager $used_if_wanted from subdirectory" "
sane_unset GIT_PAGER &&
rm -f core.pager_used &&
rm -fr sub &&
PAGER=wc &&
stampname=\$(pwd)/core.pager_used &&
export PAGER stampname &&
test_config core.pager 'wc >\"\$stampname\"' &&
mkdir sub &&
(
cd sub &&
$full_command
) &&
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
${if_local_config}test -e core.pager_used
"
}
test_GIT_PAGER_overrides() {
parse_args "$@"
$test_expectation TTY "$cmd - GIT_PAGER overrides core.pager" "
rm -f GIT_PAGER_used &&
test_config core.pager wc &&
GIT_PAGER='wc >GIT_PAGER_used' &&
export GIT_PAGER &&
$full_command &&
test -e GIT_PAGER_used
"
}
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
test_doesnt_paginate() {
parse_args "$@"
$test_expectation TTY "no pager for '$cmd'" "
rm -f GIT_PAGER_used &&
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
GIT_PAGER='wc >GIT_PAGER_used' &&
export GIT_PAGER &&
$full_command &&
! test -e GIT_PAGER_used
"
}
test_pager_choices() {
test_default_pager expect_success "$@"
test_PAGER_overrides expect_success "$@"
test_core_pager_overrides expect_success "$@"
test_core_pager_subdir expect_success "$@"
test_GIT_PAGER_overrides expect_success "$@"
}
test_expect_success 'setup: some aliases' '
git config alias.aliasedlog log &&
git config alias.true "!true"
'
test_pager_choices 'git log'
test_pager_choices 'git -p log'
test_pager_choices 'git aliasedlog'
test_default_pager expect_success 'git -p aliasedlog'
test_PAGER_overrides expect_success 'git -p aliasedlog'
test_core_pager_overrides expect_success 'git -p aliasedlog'
test_core_pager_subdir expect_failure 'git -p aliasedlog'
test_GIT_PAGER_overrides expect_success 'git -p aliasedlog'
test_default_pager expect_success 'git -p true'
test_PAGER_overrides expect_success 'git -p true'
test_core_pager_overrides expect_success 'git -p true'
test_core_pager_subdir expect_failure 'git -p true'
test_GIT_PAGER_overrides expect_success 'git -p true'
test_default_pager expect_success test_must_fail 'git -p request-pull'
test_PAGER_overrides expect_success test_must_fail 'git -p request-pull'
test_core_pager_overrides expect_success test_must_fail 'git -p request-pull'
test_core_pager_subdir expect_failure test_must_fail 'git -p request-pull'
test_GIT_PAGER_overrides expect_success test_must_fail 'git -p request-pull'
test_default_pager expect_success test_must_fail 'git -p'
test_PAGER_overrides expect_success test_must_fail 'git -p'
git --paginate: do not commit pager choice too early When git is passed the --paginate option, starting up a pager requires deciding what pager to start, which requires access to the core.pager configuration. At the relevant moment, the repository has not been searched for yet. Attempting to access the configuration at this point results in git_dir being set to .git [*], which is almost certainly not what was wanted. In particular, when run from a subdirectory of the toplevel, git --paginate does not respect the core.pager setting from the current repository. [*] unless GIT_DIR or GIT_CONFIG is set So delay the pager startup when possible: 1. run_argv() already commits pager choice inside run_builtin() if a command is found. For commands that use RUN_SETUP, waiting until then fixes the problem described above: once git knows where to look, it happily respects the core.pager setting. 2. list_common_cmds_help() prints out 29 lines and exits. This can benefit from pagination, so we need to commit the pager choice before writing this output. Luckily ‘git’ without subcommand has no other reason to access a repository, so it would be intuitive to ignore repository-local configuration in this case. Simpler for now to choose a pager using the funny code that notices a repository that happens to be at .git. That this accesses a repository when it is very convenient to is a bug but not an important one. 3. help_unknown_cmd() prints out a few lines to stderr. It is not important to paginate this, so don’t. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
test_local_config_ignored expect_failure test_must_fail 'git -p'
test_GIT_PAGER_overrides expect_success test_must_fail 'git -p'
test_expect_failure TTY 'core.pager in repo config works and retains cwd' '
sane_unset GIT_PAGER &&
test_config core.pager "cat >cwd-retained" &&
(
cd sub &&
rm -f cwd-retained &&
test_terminal git -p rev-parse HEAD &&
test_path_is_file cwd-retained
)
'
test_doesnt_paginate expect_failure test_must_fail 'git -p nonsense'
test_pager_choices 'git shortlog'
test_expect_success 'setup: configure shortlog not to paginate' '
git config pager.shortlog false
'
test_doesnt_paginate expect_success 'git shortlog'
test_no_local_config_subdir expect_success 'git shortlog'
test_default_pager expect_success 'git -p shortlog'
test_core_pager_subdir expect_success 'git -p shortlog'
test_core_pager_subdir expect_success test_must_fail \
'git -p apply </dev/null'
test_expect_success TTY 'command-specific pager' '
sane_unset PAGER GIT_PAGER &&
echo "foo:initial" >expect &&
>actual &&
test_unconfig core.pager &&
test_config pager.log "sed s/^/foo:/ >actual" &&
test_terminal git log --format=%s -1 &&
test_cmp expect actual
'
test_expect_success TTY 'command-specific pager overrides core.pager' '
sane_unset PAGER GIT_PAGER &&
echo "foo:initial" >expect &&
>actual &&
test_config core.pager "exit 1" &&
test_config pager.log "sed s/^/foo:/ >actual" &&
test_terminal git log --format=%s -1 &&
test_cmp expect actual
'
test_expect_success TTY 'command-specific pager overridden by environment' '
GIT_PAGER="sed s/^/foo:/ >actual" && export GIT_PAGER &&
>actual &&
echo "foo:initial" >expect &&
test_config pager.log "exit 1" &&
test_terminal git log --format=%s -1 &&
test_cmp expect actual
'
test_expect_success 'setup external command' '
cat >git-external <<-\EOF &&
#!/bin/sh
git "$@"
EOF
chmod +x git-external
'
test_expect_success TTY 'command-specific pager works for external commands' '
sane_unset PAGER GIT_PAGER &&
echo "foo:initial" >expect &&
>actual &&
test_config pager.external "sed s/^/foo:/ >actual" &&
test_terminal git --exec-path="$(pwd)" external log --format=%s -1 &&
test_cmp expect actual
'
test_expect_success TTY 'sub-commands of externals use their own pager' '
sane_unset PAGER GIT_PAGER &&
echo "foo:initial" >expect &&
>actual &&
test_config pager.log "sed s/^/foo:/ >actual" &&
test_terminal git --exec-path=. external log --format=%s -1 &&
test_cmp expect actual
'
test_expect_success TTY 'external command pagers override sub-commands' '
sane_unset PAGER GIT_PAGER &&
>expect &&
>actual &&
test_config pager.external false &&
test_config pager.log "sed s/^/log:/ >actual" &&
test_terminal git --exec-path=. external log --format=%s -1 &&
test_cmp expect actual
'
config: silence warnings for command names with invalid keys 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-08-24 08:11:33 +02:00
test_expect_success 'command with underscores does not complain' '
write_script git-under_score <<-\EOF &&
echo ok
EOF
git --exec-path=. under_score >actual 2>&1 &&
echo ok >expect &&
test_cmp expect actual
'
test_done