2010-02-19 10:18:58 +03:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='Test automatic use of a pager.'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
2010-06-12 20:36:51 +04:00
|
|
|
. "$TEST_DIRECTORY"/lib-pager.sh
|
2010-10-16 22:36:56 +04:00
|
|
|
. "$TEST_DIRECTORY"/lib-terminal.sh
|
2010-02-19 10:18:58 +03:00
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
2010-10-04 00:00:14 +04:00
|
|
|
sane_unset GIT_PAGER GIT_PAGER_IN_USE &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_unconfig core.pager &&
|
2010-04-15 04:38:07 +04:00
|
|
|
|
|
|
|
PAGER="cat >paginated.out" &&
|
|
|
|
export PAGER &&
|
|
|
|
|
2010-02-19 10:18:58 +03:00
|
|
|
test_commit initial
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'some commands use a pager' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 11:50:25 +03:00
|
|
|
test_terminal git log &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
2010-08-06 07:12:46 +04:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2014-01-07 06:14:05 +04:00
|
|
|
test_expect_success TTY 'LESS and LV envvars are set for pagination' '
|
|
|
|
(
|
|
|
|
sane_unset LESS LV &&
|
2014-01-30 20:42:32 +04:00
|
|
|
PAGER="env >pager-env.out; wc" &&
|
2014-01-07 06:14:05 +04:00
|
|
|
export PAGER &&
|
|
|
|
|
|
|
|
test_terminal git log
|
|
|
|
) &&
|
|
|
|
grep ^LESS= pager-env.out &&
|
|
|
|
grep ^LV= pager-env.out
|
|
|
|
'
|
|
|
|
|
2016-08-04 14:40:25 +03:00
|
|
|
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 &&
|
2018-11-19 22:34:13 +03:00
|
|
|
PATH="$(git --exec-path)$PATH_SEP$PATH" &&
|
2016-08-04 14:40:25 +03:00
|
|
|
export PATH &&
|
|
|
|
test_terminal sh -c ". git-sh-setup && git_pager"
|
|
|
|
) &&
|
|
|
|
grep ^LESS= pager-env.out &&
|
|
|
|
grep ^LV= pager-env.out
|
|
|
|
'
|
|
|
|
|
2010-02-19 10:18:58 +03:00
|
|
|
test_expect_success TTY 'some commands do not use a pager' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 11:50:25 +03:00
|
|
|
test_terminal git rev-list HEAD &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no pager when stdout is a pipe' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f paginated.out &&
|
2010-02-19 10:18:58 +03:00
|
|
|
git log | cat &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no pager when stdout is a regular file' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f paginated.out &&
|
2010-04-15 04:38:07 +04:00
|
|
|
git log >file &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git --paginate rev-list uses a pager' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 11:50:25 +03:00
|
|
|
test_terminal git --paginate rev-list HEAD &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no pager even with --paginate when stdout is a pipe' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f file paginated.out &&
|
2010-02-19 10:18:58 +03:00
|
|
|
git --paginate log | cat &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'no pager with --no-pager' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 11:50:25 +03:00
|
|
|
test_terminal git --no-pager log &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
2010-08-06 07:06:39 +04:00
|
|
|
test_expect_success TTY 'configuration can disable pager' '
|
|
|
|
rm -f paginated.out &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_unconfig pager.grep &&
|
2010-08-06 07:06:39 +04:00
|
|
|
test_terminal git grep initial &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out &&
|
2010-08-06 07:06:39 +04:00
|
|
|
|
|
|
|
rm -f paginated.out &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_config pager.grep false &&
|
2010-08-06 07:06:39 +04:00
|
|
|
test_terminal git grep initial &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2010-08-06 07:06:39 +04:00
|
|
|
'
|
|
|
|
|
2010-08-16 12:08:34 +04:00
|
|
|
test_expect_success TTY 'configuration can enable pager (from subdir)' '
|
2010-08-06 07:12:46 +04:00
|
|
|
rm -f paginated.out &&
|
|
|
|
mkdir -p subdir &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_config pager.bundle true &&
|
2010-08-06 07:12:46 +04:00
|
|
|
|
|
|
|
git bundle create test.bundle --all &&
|
|
|
|
rm -f paginated.out subdir/paginated.out &&
|
|
|
|
(
|
|
|
|
cd subdir &&
|
|
|
|
test_terminal git bundle unbundle ../test.bundle
|
|
|
|
) &&
|
|
|
|
{
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out ||
|
|
|
|
test_path_is_file subdir/paginated.out
|
2010-08-06 07:12:46 +04:00
|
|
|
}
|
|
|
|
'
|
|
|
|
|
2017-08-02 22:40:54 +03:00
|
|
|
test_expect_success TTY 'git tag -l defaults to paging' '
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git tag -l &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag -l respects pager.tag' '
|
|
|
|
rm -f paginated.out &&
|
2017-08-02 22:40:54 +03:00
|
|
|
test_terminal git -c pager.tag=false tag -l &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag -l respects --no-pager' '
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.tag --no-pager tag -l &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
2017-08-02 22:40:54 +03:00
|
|
|
test_expect_success TTY 'git tag with no args defaults to paging' '
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
# no args implies -l so this should page like -l
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git tag &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag with no args respects pager.tag' '
|
|
|
|
# no args implies -l so this should page like -l
|
|
|
|
rm -f paginated.out &&
|
2017-08-02 22:40:54 +03:00
|
|
|
test_terminal git -c pager.tag=false tag &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
2017-08-02 22:40:54 +03:00
|
|
|
test_expect_success TTY 'git tag --contains defaults to paging' '
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
# --contains implies -l so this should page like -l
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git tag --contains &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag --contains respects pager.tag' '
|
|
|
|
# --contains implies -l so this should page like -l
|
|
|
|
rm -f paginated.out &&
|
2017-08-02 22:40:54 +03:00
|
|
|
test_terminal git -c pager.tag=false tag --contains &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag -a defaults to not paging' '
|
|
|
|
test_when_finished "git tag -d newtag" &&
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git tag -am message newtag &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
2017-08-02 22:40:53 +03:00
|
|
|
test_expect_success TTY 'git tag -a ignores pager.tag' '
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
test_when_finished "git tag -d newtag" &&
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.tag tag -am message newtag &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag -a respects --paginate' '
|
|
|
|
test_when_finished "git tag -d newtag" &&
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git --paginate tag -am message newtag &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
t7006: add tests for how git tag paginates
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-08-02 22:40:52 +03:00
|
|
|
'
|
|
|
|
|
git.c: ignore pager.* when launching builtin as dashed external
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-02 22:40:55 +03:00
|
|
|
test_expect_success TTY 'git tag as alias ignores pager.tag with -a' '
|
2017-08-02 22:40:53 +03:00
|
|
|
test_when_finished "git tag -d newtag" &&
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.tag -c alias.t=tag t -am message newtag &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2017-08-02 22:40:53 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag as alias respects pager.tag with -l' '
|
|
|
|
rm -f paginated.out &&
|
2017-08-02 22:40:54 +03:00
|
|
|
test_terminal git -c pager.tag=false -c alias.t=tag t -l &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2017-08-02 22:40:53 +03:00
|
|
|
'
|
|
|
|
|
2017-11-19 18:03:50 +03:00
|
|
|
test_expect_success TTY 'git branch defaults to paging' '
|
2017-11-19 18:03:48 +03:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git branch &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
2017-11-19 18:03:48 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git branch respects pager.branch' '
|
|
|
|
rm -f paginated.out &&
|
2017-11-19 18:03:50 +03:00
|
|
|
test_terminal git -c pager.branch=false branch &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2017-11-19 18:03:48 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git branch respects --no-pager' '
|
|
|
|
rm -f paginated.out &&
|
2017-11-19 18:03:50 +03:00
|
|
|
test_terminal git --no-pager branch &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2017-11-19 18:03:48 +03:00
|
|
|
'
|
|
|
|
|
2017-11-19 18:03:49 +03:00
|
|
|
test_expect_success TTY 'git branch --edit-description ignores pager.branch' '
|
2017-11-19 18:03:48 +03:00
|
|
|
rm -f paginated.out editor.used &&
|
|
|
|
write_script editor <<-\EOF &&
|
|
|
|
echo "New description" >"$1"
|
|
|
|
touch editor.used
|
|
|
|
EOF
|
|
|
|
EDITOR=./editor test_terminal git -c pager.branch branch --edit-description &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out &&
|
|
|
|
test_path_is_file editor.used
|
2017-11-19 18:03:48 +03:00
|
|
|
'
|
|
|
|
|
2017-11-19 18:03:49 +03:00
|
|
|
test_expect_success TTY 'git branch --set-upstream-to ignores pager.branch' '
|
2017-11-19 18:03:48 +03:00
|
|
|
rm -f paginated.out &&
|
|
|
|
git branch other &&
|
|
|
|
test_when_finished "git branch -D other" &&
|
|
|
|
test_terminal git -c pager.branch branch --set-upstream-to=other &&
|
|
|
|
test_when_finished "git branch --unset-upstream" &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
2017-11-19 18:03:48 +03:00
|
|
|
'
|
|
|
|
|
2018-02-21 21:51:43 +03:00
|
|
|
test_expect_success TTY 'git config ignores pager.config when setting' '
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.config config foo.bar bar &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
'
|
|
|
|
|
2018-02-21 21:51:43 +03:00
|
|
|
test_expect_success TTY 'git config --edit ignores pager.config' '
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
rm -f paginated.out editor.used &&
|
|
|
|
write_script editor <<-\EOF &&
|
|
|
|
touch editor.used
|
|
|
|
EOF
|
|
|
|
EDITOR=./editor test_terminal git -c pager.config config --edit &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out &&
|
|
|
|
test_path_is_file editor.used
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
'
|
|
|
|
|
2018-02-21 21:51:43 +03:00
|
|
|
test_expect_success TTY 'git config --get ignores pager.config' '
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.config config --get foo.bar &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
'
|
|
|
|
|
2018-02-21 21:51:44 +03:00
|
|
|
test_expect_success TTY 'git config --get-urlmatch defaults to paging' '
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c http."https://foo.com/".bar=foo \
|
|
|
|
config --get-urlmatch http https://foo.com &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git config --get-all respects pager.config' '
|
|
|
|
rm -f paginated.out &&
|
2018-02-21 21:51:44 +03:00
|
|
|
test_terminal git -c pager.config=false config --get-all foo.bar &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing paginated.out
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
'
|
|
|
|
|
2018-02-21 21:51:44 +03:00
|
|
|
test_expect_success TTY 'git config --list defaults to paging' '
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git config --list &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file paginated.out
|
t7006: add tests for how git config paginates
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>
2018-02-21 21:51:42 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
|
2010-02-19 10:18:58 +03:00
|
|
|
# A colored commit log will begin with an appropriate ANSI escape
|
|
|
|
# for the first color; the text "commit" comes later.
|
|
|
|
colorful() {
|
2010-04-15 04:38:07 +04:00
|
|
|
read firstline <$1
|
2010-06-21 22:18:54 +04:00
|
|
|
! expr "$firstline" : "[a-zA-Z]" >/dev/null
|
2010-02-19 10:18:58 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success 'tests can detect color' '
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f colorful.log colorless.log &&
|
2010-04-15 04:38:07 +04:00
|
|
|
git log --no-color >colorless.log &&
|
|
|
|
git log --color >colorful.log &&
|
2010-02-19 10:18:58 +03:00
|
|
|
! colorful colorless.log &&
|
|
|
|
colorful colorful.log
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no color when stdout is a regular file' '
|
2010-04-15 04:38:07 +04:00
|
|
|
rm -f colorless.log &&
|
2011-12-14 12:22:03 +04:00
|
|
|
test_config color.ui auto &&
|
2010-04-15 04:38:07 +04:00
|
|
|
git log >colorless.log &&
|
2010-02-19 10:18:58 +03:00
|
|
|
! colorful colorless.log
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'color when writing to a pager' '
|
2010-04-15 04:38:07 +04:00
|
|
|
rm -f paginated.out &&
|
2011-12-14 12:22:03 +04:00
|
|
|
test_config color.ui auto &&
|
2017-10-03 16:39:34 +03:00
|
|
|
test_terminal git log &&
|
2010-02-19 10:18:58 +03:00
|
|
|
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 09:04:23 +04: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 &&
|
2017-10-03 16:39:34 +03:00
|
|
|
test_terminal 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 09:04:23 +04:00
|
|
|
! colorful paginated.out
|
|
|
|
'
|
|
|
|
|
2010-02-19 10:18:58 +03:00
|
|
|
test_expect_success 'color when writing to a file intended for a pager' '
|
2010-04-15 04:38:07 +04:00
|
|
|
rm -f colorful.log &&
|
2011-12-14 12:22:03 +04:00
|
|
|
test_config color.ui auto &&
|
2010-04-15 04:38:07 +04:00
|
|
|
(
|
|
|
|
TERM=vt100 &&
|
|
|
|
GIT_PAGER_IN_USE=true &&
|
|
|
|
export TERM GIT_PAGER_IN_USE &&
|
|
|
|
git log >colorful.log
|
|
|
|
) &&
|
2010-02-19 10:18:58 +03:00
|
|
|
colorful colorful.log
|
|
|
|
'
|
|
|
|
|
2011-08-18 09:02:29 +04:00
|
|
|
test_expect_success TTY 'colors are sent to pager for external commands' '
|
|
|
|
test_config alias.externallog "!git log" &&
|
|
|
|
test_config color.ui auto &&
|
2017-10-03 16:39:34 +03:00
|
|
|
test_terminal git -p externallog &&
|
2011-08-18 09:02:29 +04:00
|
|
|
colorful paginated.out
|
|
|
|
'
|
|
|
|
|
2010-06-26 23:23:02 +04:00
|
|
|
# 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"
|
|
|
|
}
|
2010-04-15 04:38:07 +04:00
|
|
|
|
2010-06-26 23:24:50 +04:00
|
|
|
test_default_pager() {
|
|
|
|
parse_args "$@"
|
|
|
|
|
2010-10-16 22:36:59 +04:00
|
|
|
$test_expectation SIMPLEPAGER,TTY "$cmd - default pager is used by default" "
|
2010-10-04 00:00:14 +04:00
|
|
|
sane_unset PAGER GIT_PAGER &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_unconfig core.pager &&
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f default_pager_used &&
|
2010-06-26 23:24:50 +04:00
|
|
|
cat >\$less <<-\EOF &&
|
|
|
|
#!/bin/sh
|
|
|
|
wc >default_pager_used
|
|
|
|
EOF
|
|
|
|
chmod +x \$less &&
|
|
|
|
(
|
2018-11-19 22:34:13 +03:00
|
|
|
PATH=.$PATH_SEP\$PATH &&
|
2010-06-26 23:24:50 +04:00
|
|
|
export PATH &&
|
|
|
|
$full_command
|
|
|
|
) &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file default_pager_used
|
2010-06-26 23:24:50 +04:00
|
|
|
"
|
|
|
|
}
|
2010-02-19 10:18:58 +03:00
|
|
|
|
2010-06-26 23:24:50 +04:00
|
|
|
test_PAGER_overrides() {
|
|
|
|
parse_args "$@"
|
2010-04-15 04:38:07 +04:00
|
|
|
|
2010-06-26 23:24:50 +04:00
|
|
|
$test_expectation TTY "$cmd - PAGER overrides default pager" "
|
2010-10-04 00:00:14 +04:00
|
|
|
sane_unset GIT_PAGER &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_unconfig core.pager &&
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f PAGER_used &&
|
2010-06-26 23:24:50 +04:00
|
|
|
PAGER='wc >PAGER_used' &&
|
|
|
|
export PAGER &&
|
|
|
|
$full_command &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file PAGER_used
|
2010-06-26 23:24:50 +04:00
|
|
|
"
|
|
|
|
}
|
2010-04-15 04:38:07 +04:00
|
|
|
|
2010-06-26 23:24:50 +04:00
|
|
|
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 23:26:37 +04:00
|
|
|
if_local_config=
|
|
|
|
used_if_wanted='overrides PAGER'
|
|
|
|
test_core_pager "$@"
|
|
|
|
}
|
2010-02-19 10:18:58 +03:00
|
|
|
|
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 23:26:37 +04:00
|
|
|
test_local_config_ignored() {
|
|
|
|
if_local_config='! '
|
|
|
|
used_if_wanted='is not used'
|
|
|
|
test_core_pager "$@"
|
|
|
|
}
|
2010-04-15 04:38:07 +04:00
|
|
|
|
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 23:26:37 +04:00
|
|
|
test_core_pager() {
|
2010-06-26 23:24:50 +04:00
|
|
|
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 23:26:37 +04:00
|
|
|
$test_expectation TTY "$cmd - repository-local core.pager setting $used_if_wanted" "
|
2010-10-04 00:00:14 +04:00
|
|
|
sane_unset GIT_PAGER &&
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f core.pager_used &&
|
2010-06-26 23:24:50 +04:00
|
|
|
PAGER=wc &&
|
|
|
|
export PAGER &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_config core.pager 'wc >core.pager_used' &&
|
2010-06-26 23:24:50 +04:00
|
|
|
$full_command &&
|
2020-10-20 22:53:52 +03:00
|
|
|
${if_local_config}test_path_is_file core.pager_used
|
2010-06-26 23:24:50 +04:00
|
|
|
"
|
|
|
|
}
|
|
|
|
|
2010-06-26 23:25:37 +04:00
|
|
|
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 23:26:37 +04: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() {
|
2010-06-26 23:25:37 +04:00
|
|
|
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 23:26:37 +04:00
|
|
|
$test_expectation TTY "$cmd - core.pager $used_if_wanted from subdirectory" "
|
2010-10-04 00:00:14 +04:00
|
|
|
sane_unset GIT_PAGER &&
|
2010-06-26 23:25:37 +04:00
|
|
|
rm -f core.pager_used &&
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -fr sub &&
|
2010-06-26 23:25:37 +04:00
|
|
|
PAGER=wc &&
|
|
|
|
stampname=\$(pwd)/core.pager_used &&
|
|
|
|
export PAGER stampname &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_config core.pager 'wc >\"\$stampname\"' &&
|
2010-06-26 23:25:37 +04:00
|
|
|
mkdir sub &&
|
|
|
|
(
|
|
|
|
cd sub &&
|
|
|
|
$full_command
|
|
|
|
) &&
|
2020-10-20 22:53:52 +03:00
|
|
|
${if_local_config}test_path_is_file core.pager_used
|
2010-06-26 23:25:37 +04:00
|
|
|
"
|
|
|
|
}
|
|
|
|
|
2010-06-26 23:24:50 +04:00
|
|
|
test_GIT_PAGER_overrides() {
|
|
|
|
parse_args "$@"
|
|
|
|
|
|
|
|
$test_expectation TTY "$cmd - GIT_PAGER overrides core.pager" "
|
2011-12-14 12:22:03 +04:00
|
|
|
rm -f GIT_PAGER_used &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_config core.pager wc &&
|
2010-06-26 23:24:50 +04:00
|
|
|
GIT_PAGER='wc >GIT_PAGER_used' &&
|
|
|
|
export GIT_PAGER &&
|
|
|
|
$full_command &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_file GIT_PAGER_used
|
2010-06-26 23:24:50 +04:00
|
|
|
"
|
|
|
|
}
|
2010-04-15 04:38:07 +04:00
|
|
|
|
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 23:26:37 +04:00
|
|
|
test_doesnt_paginate() {
|
|
|
|
parse_args "$@"
|
|
|
|
|
|
|
|
$test_expectation TTY "no pager for '$cmd'" "
|
2011-12-14 12:22:03 +04:00
|
|
|
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 23:26:37 +04:00
|
|
|
GIT_PAGER='wc >GIT_PAGER_used' &&
|
|
|
|
export GIT_PAGER &&
|
|
|
|
$full_command &&
|
2020-10-20 22:53:52 +03:00
|
|
|
test_path_is_missing 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 23:26:37 +04:00
|
|
|
"
|
|
|
|
}
|
|
|
|
|
2010-07-15 02:55:12 +04:00
|
|
|
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"
|
2010-02-19 10:18:58 +03:00
|
|
|
'
|
|
|
|
|
2010-07-15 02:55:12 +04:00
|
|
|
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'
|
2017-03-13 23:11:12 +03:00
|
|
|
test_core_pager_subdir expect_success 'git -p aliasedlog'
|
2010-07-15 02:55:12 +04:00
|
|
|
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'
|
2017-03-13 23:11:12 +03:00
|
|
|
test_core_pager_subdir expect_success 'git -p true'
|
2010-07-15 02:55:12 +04:00
|
|
|
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'
|
2017-03-13 23:11:12 +03:00
|
|
|
test_core_pager_subdir expect_success test_must_fail 'git -p request-pull'
|
2010-07-15 02:55:12 +04:00
|
|
|
test_GIT_PAGER_overrides expect_success test_must_fail 'git -p request-pull'
|
2010-06-26 23:24:50 +04:00
|
|
|
|
|
|
|
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 23:26:37 +04:00
|
|
|
test_local_config_ignored expect_failure test_must_fail 'git -p'
|
2010-06-26 23:24:50 +04:00
|
|
|
test_GIT_PAGER_overrides expect_success test_must_fail 'git -p'
|
|
|
|
|
2017-03-13 23:11:12 +03:00
|
|
|
test_expect_success TTY 'core.pager in repo config works and retains cwd' '
|
t7006: replace dubious test
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>
2017-03-03 20:32:01 +03:00
|
|
|
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
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2017-06-14 14:36:00 +03:00
|
|
|
test_expect_success TTY 'core.pager is found via alias in subdirectory' '
|
2017-06-14 14:35:56 +03:00
|
|
|
sane_unset GIT_PAGER &&
|
|
|
|
test_config core.pager "cat >via-alias" &&
|
|
|
|
(
|
|
|
|
cd sub &&
|
|
|
|
rm -f via-alias &&
|
|
|
|
test_terminal git -c alias.r="-p rev-parse" r HEAD &&
|
|
|
|
test_path_is_file via-alias
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2010-07-15 02:55:12 +04:00
|
|
|
test_doesnt_paginate expect_failure test_must_fail 'git -p nonsense'
|
2010-02-19 10:18:58 +03:00
|
|
|
|
2010-08-06 07:01:37 +04:00
|
|
|
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'
|
|
|
|
|
2010-08-16 04:36:12 +04:00
|
|
|
test_core_pager_subdir expect_success test_must_fail \
|
|
|
|
'git -p apply </dev/null'
|
|
|
|
|
2010-11-17 20:04:12 +03:00
|
|
|
test_expect_success TTY 'command-specific pager' '
|
2011-08-18 09:00:47 +04:00
|
|
|
sane_unset PAGER GIT_PAGER &&
|
2010-11-17 20:04:12 +03:00
|
|
|
echo "foo:initial" >expect &&
|
|
|
|
>actual &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_unconfig core.pager &&
|
|
|
|
test_config pager.log "sed s/^/foo:/ >actual" &&
|
2010-11-17 20:04:12 +03:00
|
|
|
test_terminal git log --format=%s -1 &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'command-specific pager overrides core.pager' '
|
2011-08-18 09:00:47 +04:00
|
|
|
sane_unset PAGER GIT_PAGER &&
|
2010-11-17 20:04:12 +03:00
|
|
|
echo "foo:initial" >expect &&
|
|
|
|
>actual &&
|
2015-03-20 13:07:15 +03:00
|
|
|
test_config core.pager "exit 1" &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_config pager.log "sed s/^/foo:/ >actual" &&
|
2010-11-17 20:04:12 +03:00
|
|
|
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 &&
|
2011-08-18 09:02:06 +04:00
|
|
|
test_config pager.log "exit 1" &&
|
2010-11-17 20:04:12 +03:00
|
|
|
test_terminal git log --format=%s -1 &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2011-08-19 02:01:32 +04:00
|
|
|
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" &&
|
2016-01-07 16:51:50 +03:00
|
|
|
test_terminal git --exec-path="$(pwd)" external log --format=%s -1 &&
|
2011-08-19 02:01:32 +04:00
|
|
|
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 &&
|
|
|
|
>actual &&
|
|
|
|
test_config pager.external false &&
|
|
|
|
test_config pager.log "sed s/^/log:/ >actual" &&
|
|
|
|
test_terminal git --exec-path=. external log --format=%s -1 &&
|
2018-07-27 20:48:11 +03:00
|
|
|
test_must_be_empty actual
|
2011-08-19 02:01:32 +04:00
|
|
|
'
|
|
|
|
|
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 09:11:33 +03: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
|
|
|
|
'
|
|
|
|
|
2017-10-16 21:35:11 +03:00
|
|
|
test_expect_success TTY 'git tag with auto-columns ' '
|
|
|
|
test_commit one &&
|
|
|
|
test_commit two &&
|
|
|
|
test_commit three &&
|
|
|
|
test_commit four &&
|
|
|
|
test_commit five &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
initial one two three four five
|
|
|
|
EOF
|
|
|
|
test_terminal env PAGER="cat >actual" COLUMNS=80 \
|
|
|
|
git -c column.ui=auto tag --sort=authordate &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2021-02-02 05:00:00 +03:00
|
|
|
test_expect_success 'setup trace2' '
|
|
|
|
GIT_TRACE2_BRIEF=1 &&
|
|
|
|
export GIT_TRACE2_BRIEF
|
|
|
|
'
|
|
|
|
|
t7006: clean up SIGPIPE handling in trace2 tests
Comit c24b7f6736 (pager: test for exit code with and without SIGPIPE,
2021-02-02) introduced some tests that don't reliably generate SIGPIPE
where we expect it (i.e., when our pager doesn't read all of the output
from git-log).
There are two problems that somewhat cancel each other out.
First is that the output of git-log isn't very large (only around 800
bytes). So even if the pager doesn't read all of our output, it's racy
whether or not we'll actually get a SIGPIPE (we won't if we write all of
the output into the pipe buffer before the pager exits).
But we wrap git-log with test_terminal, which is supposed to propagate
the exit status of git-log. However, it doesn't always do so;
test_terminal will copy to stdout any lines that it got from our fake
pager, and it pipes to an empty command. So most of the time we are
seeing a SIGPIPE from test_terminal itself (though this is likewise
racy).
Let's try to make this more robust in two ways:
1. We'll put a commit with a huge message at the tip of history. Since
this is over a megabyte, it should fill the OS pipe buffer
completely, causing git-log to keep trying to write even after the
pager has exited.
2. We'll redirect the output of test_terminal to /dev/null. That means
it can never get SIGPIPE itself, and will always be giving us the
exit code from git-log.
These two changes reveal that one of the tests was looking for the wrong
behavior. If we try to start a pager that does not exist (according to
execve()), then the error propagates from start_command() back to the
pager code as an error, and we avoid redirecting git-log's stdout to the
broken pager entirely. Instead, it goes straight to the original stdout
(test_terminal's pty in this case), and we do not see a SIGPIPE at all.
So the test "git attempts to page to nonexisting pager command, gets
SIGPIPE" is checking the wrong outcome; it should be looking for a
successful exit (and was only confused by test_terminal's SIGPIPE).
There's a related test, "git discards nonexisting pager without
SIGPIPE", which sets the pager to a shell command which will read all
input and _then_ run a non-existing command. But that doesn't trigger
the same execve() behavior. We really do run the shell there and
redirect git-log's stdout to it. And the fact that the shell then exits
127 is not interesting. It is not different at that point than the
earlier test to check for "exit 1". So we can drop that test entirely.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22 01:54:39 +03:00
|
|
|
test_expect_success 'setup large log output' '
|
|
|
|
perl -e "
|
|
|
|
print \"this is a long commit message\" x 50000
|
|
|
|
" >commit-msg &&
|
|
|
|
git commit --allow-empty -F commit-msg
|
|
|
|
'
|
|
|
|
|
2021-02-02 04:59:58 +03:00
|
|
|
test_expect_success TTY 'git returns SIGPIPE on early pager exit' '
|
2021-02-02 05:00:00 +03:00
|
|
|
test_when_finished "rm pager-used trace.normal" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_config core.pager ">pager-used; head -n 1; exit 0" &&
|
2021-02-02 05:00:00 +03:00
|
|
|
GIT_TRACE2="$(pwd)/trace.normal" &&
|
|
|
|
export GIT_TRACE2 &&
|
|
|
|
test_when_finished "unset GIT_TRACE2" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
|
|
|
|
if test_have_prereq !MINGW
|
|
|
|
then
|
t7006: simplify exit-code checks for sigpipe tests
Some tests in t7006 check for a SIGPIPE result by recording $? and
comparing it with test_match_signal. Before the previous commit, the
command was on the left-hand side of a pipe, and so we had to do some
subshell trickery to extract it.
But now that this is no longer the case, we can do things much more
simply: just run the command directly, using braces to avoid wrecking
the &&-chain, and then record $?. We could almost use test_expect_code
here, but it doesn't know about test_match_signal.
Likewise, for tests which expect success (i.e., not SIGPIPE), we can
just put them in the &&-chain as usual. That even lets us get rid of the
!MINGW check, since the expectation is the same on both sides.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22 02:10:56 +03:00
|
|
|
{ test_terminal git log >/dev/null; OUT=$?; } &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_match_signal 13 "$OUT"
|
|
|
|
else
|
|
|
|
test_terminal git log
|
|
|
|
fi &&
|
2021-02-02 05:00:00 +03:00
|
|
|
|
|
|
|
grep child_exit trace.normal >child-exits &&
|
|
|
|
test_line_count = 1 child-exits &&
|
|
|
|
grep " code:0 " child-exits &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_path_is_file pager-used
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git returns SIGPIPE on early pager non-zero exit' '
|
2021-02-02 05:00:00 +03:00
|
|
|
test_when_finished "rm pager-used trace.normal" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_config core.pager ">pager-used; head -n 1; exit 1" &&
|
2021-02-02 05:00:00 +03:00
|
|
|
GIT_TRACE2="$(pwd)/trace.normal" &&
|
|
|
|
export GIT_TRACE2 &&
|
|
|
|
test_when_finished "unset GIT_TRACE2" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
|
|
|
|
if test_have_prereq !MINGW
|
|
|
|
then
|
t7006: simplify exit-code checks for sigpipe tests
Some tests in t7006 check for a SIGPIPE result by recording $? and
comparing it with test_match_signal. Before the previous commit, the
command was on the left-hand side of a pipe, and so we had to do some
subshell trickery to extract it.
But now that this is no longer the case, we can do things much more
simply: just run the command directly, using braces to avoid wrecking
the &&-chain, and then record $?. We could almost use test_expect_code
here, but it doesn't know about test_match_signal.
Likewise, for tests which expect success (i.e., not SIGPIPE), we can
just put them in the &&-chain as usual. That even lets us get rid of the
!MINGW check, since the expectation is the same on both sides.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22 02:10:56 +03:00
|
|
|
{ test_terminal git log >/dev/null; OUT=$?; } &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_match_signal 13 "$OUT"
|
|
|
|
else
|
|
|
|
test_terminal git log
|
|
|
|
fi &&
|
2021-02-02 05:00:00 +03:00
|
|
|
|
|
|
|
grep child_exit trace.normal >child-exits &&
|
|
|
|
test_line_count = 1 child-exits &&
|
|
|
|
grep " code:1 " child-exits &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_path_is_file pager-used
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git discards pager non-zero exit without SIGPIPE' '
|
2021-02-02 05:00:00 +03:00
|
|
|
test_when_finished "rm pager-used trace.normal" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_config core.pager "wc >pager-used; exit 1" &&
|
2021-02-02 05:00:00 +03:00
|
|
|
GIT_TRACE2="$(pwd)/trace.normal" &&
|
|
|
|
export GIT_TRACE2 &&
|
|
|
|
test_when_finished "unset GIT_TRACE2" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
|
t7006: simplify exit-code checks for sigpipe tests
Some tests in t7006 check for a SIGPIPE result by recording $? and
comparing it with test_match_signal. Before the previous commit, the
command was on the left-hand side of a pipe, and so we had to do some
subshell trickery to extract it.
But now that this is no longer the case, we can do things much more
simply: just run the command directly, using braces to avoid wrecking
the &&-chain, and then record $?. We could almost use test_expect_code
here, but it doesn't know about test_match_signal.
Likewise, for tests which expect success (i.e., not SIGPIPE), we can
just put them in the &&-chain as usual. That even lets us get rid of the
!MINGW check, since the expectation is the same on both sides.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22 02:10:56 +03:00
|
|
|
test_terminal git log &&
|
2021-02-02 05:00:00 +03:00
|
|
|
|
|
|
|
grep child_exit trace.normal >child-exits &&
|
|
|
|
test_line_count = 1 child-exits &&
|
|
|
|
grep " code:1 " child-exits &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_path_is_file pager-used
|
|
|
|
'
|
|
|
|
|
t7006: clean up SIGPIPE handling in trace2 tests
Comit c24b7f6736 (pager: test for exit code with and without SIGPIPE,
2021-02-02) introduced some tests that don't reliably generate SIGPIPE
where we expect it (i.e., when our pager doesn't read all of the output
from git-log).
There are two problems that somewhat cancel each other out.
First is that the output of git-log isn't very large (only around 800
bytes). So even if the pager doesn't read all of our output, it's racy
whether or not we'll actually get a SIGPIPE (we won't if we write all of
the output into the pipe buffer before the pager exits).
But we wrap git-log with test_terminal, which is supposed to propagate
the exit status of git-log. However, it doesn't always do so;
test_terminal will copy to stdout any lines that it got from our fake
pager, and it pipes to an empty command. So most of the time we are
seeing a SIGPIPE from test_terminal itself (though this is likewise
racy).
Let's try to make this more robust in two ways:
1. We'll put a commit with a huge message at the tip of history. Since
this is over a megabyte, it should fill the OS pipe buffer
completely, causing git-log to keep trying to write even after the
pager has exited.
2. We'll redirect the output of test_terminal to /dev/null. That means
it can never get SIGPIPE itself, and will always be giving us the
exit code from git-log.
These two changes reveal that one of the tests was looking for the wrong
behavior. If we try to start a pager that does not exist (according to
execve()), then the error propagates from start_command() back to the
pager code as an error, and we avoid redirecting git-log's stdout to the
broken pager entirely. Instead, it goes straight to the original stdout
(test_terminal's pty in this case), and we do not see a SIGPIPE at all.
So the test "git attempts to page to nonexisting pager command, gets
SIGPIPE" is checking the wrong outcome; it should be looking for a
successful exit (and was only confused by test_terminal's SIGPIPE).
There's a related test, "git discards nonexisting pager without
SIGPIPE", which sets the pager to a shell command which will read all
input and _then_ run a non-existing command. But that doesn't trigger
the same execve() behavior. We really do run the shell there and
redirect git-log's stdout to it. And the fact that the shell then exits
127 is not interesting. It is not different at that point than the
earlier test to check for "exit 1". So we can drop that test entirely.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22 01:54:39 +03:00
|
|
|
test_expect_success TTY 'git skips paging nonexisting command' '
|
2021-02-02 05:00:00 +03:00
|
|
|
test_when_finished "rm trace.normal" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_config core.pager "does-not-exist" &&
|
2021-02-02 05:00:00 +03:00
|
|
|
GIT_TRACE2="$(pwd)/trace.normal" &&
|
|
|
|
export GIT_TRACE2 &&
|
|
|
|
test_when_finished "unset GIT_TRACE2" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
|
t7006: simplify exit-code checks for sigpipe tests
Some tests in t7006 check for a SIGPIPE result by recording $? and
comparing it with test_match_signal. Before the previous commit, the
command was on the left-hand side of a pipe, and so we had to do some
subshell trickery to extract it.
But now that this is no longer the case, we can do things much more
simply: just run the command directly, using braces to avoid wrecking
the &&-chain, and then record $?. We could almost use test_expect_code
here, but it doesn't know about test_match_signal.
Likewise, for tests which expect success (i.e., not SIGPIPE), we can
just put them in the &&-chain as usual. That even lets us get rid of the
!MINGW check, since the expectation is the same on both sides.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22 02:10:56 +03:00
|
|
|
test_terminal git log &&
|
2021-02-02 05:00:00 +03:00
|
|
|
|
|
|
|
grep child_exit trace.normal >child-exits &&
|
|
|
|
test_line_count = 1 child-exits &&
|
|
|
|
grep " code:-1 " child-exits
|
2021-02-02 04:59:58 +03:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git returns SIGPIPE on propagated signals from pager' '
|
2021-02-02 05:00:00 +03:00
|
|
|
test_when_finished "rm pager-used trace.normal" &&
|
run-command: unify signal and regular logic for wait_or_whine()
Since 507d7804c0 (pager: don't use unsafe functions in signal handlers,
2015-09-04), we have a separate code path in wait_or_whine() for the
case that we're in a signal handler. But that code path misses some of
the cases handled by the main logic.
This was improved in be8fc53e36 (pager: properly log pager exit code
when signalled, 2021-02-02), but that covered only case: actually
returning the correct error code. But there are some other cases:
- if waitpid() returns failure, we wouldn't notice and would look at
uninitialized garbage in the status variable; it's not clear if it's
possible to trigger this or not
- if the process exited by signal, then we would still report "-1"
rather than the correct signal code
This latter case even had a test added in be8fc53e36, but it doesn't
work reliably. It sets the pager command to:
>pager-used; test-tool sigchain
The latter command will die by signal, but because there are multiple
commands, there will be a shell in between. And it's the shell whose
waitpid() call will see the signal death, and it will then exit with
code 143, which is what Git will see.
To make matters even more confusing, some shells (such as bash) will
realize that there's nothing for the shell to do after test-tool
finishes, and will turn it into an exec. So the test was only checking
what it thought when /bin/sh points to a shell like bash (we're relying
on the shell used internally by Git to spawn sub-commands here, so even
running the test under bash would not be enough).
This patch adjusts the tests to explicitly call "exec" in the pager
command, which produces a consistent outcome regardless of shell. Note
that without the code change in this patch it _should_ fail reliably,
but doesn't. That test, like its siblings, tries to trigger SIGPIPE in
the git-log process writing to the pager, but only do so racily. That
will be fixed in a follow-on patch.
For the code change here, we have two options:
- we can teach the in_signal code to handle WIFSIGNALED()
- we can stop returning early when in_signal is set, and instead
annotate individual calls that we need to skip in this case
The former is a simpler patch, but means we're essentially duplicating
all of the logic. So instead I went with the latter. The result is a
bigger patch, and we do run the risk of new code being added but
forgetting to handle in_signal. But in the long run it seems more
maintainable.
I've skipped any non-trivial calls for the in_signal case, like calling
error(). We'll also skip the call to clear_child_for_cleanup(), as we
were before. This is arguably the wrong thing to do, since we wouldn't
want to try to clean it up again. But:
- we can't call it as-is, because it calls free(), which we must avoid
in a signal handler (we'd have to pass in_signal so it can skip the
free() call)
- we'll only go through the list of children to clean once, since our
cleanup_children_on_signal() handler pops itself after running (and
then re-raises, so eventually we'd just exit). So this cleanup only
matters if a process is on the cleanup list _and_ it has a separate
handler to clean itself up. Which is questionable in the first place
(and AFAIK we do not do).
- double-cleanup isn't actually that bad anyway. waitpid() will just
return an error, which we won't even report because of in_signal.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-23 00:28:13 +03:00
|
|
|
test_config core.pager ">pager-used; exec test-tool sigchain" &&
|
2021-02-02 05:00:00 +03:00
|
|
|
GIT_TRACE2="$(pwd)/trace.normal" &&
|
|
|
|
export GIT_TRACE2 &&
|
|
|
|
test_when_finished "unset GIT_TRACE2" &&
|
2021-02-02 04:59:58 +03:00
|
|
|
|
|
|
|
if test_have_prereq !MINGW
|
|
|
|
then
|
t7006: simplify exit-code checks for sigpipe tests
Some tests in t7006 check for a SIGPIPE result by recording $? and
comparing it with test_match_signal. Before the previous commit, the
command was on the left-hand side of a pipe, and so we had to do some
subshell trickery to extract it.
But now that this is no longer the case, we can do things much more
simply: just run the command directly, using braces to avoid wrecking
the &&-chain, and then record $?. We could almost use test_expect_code
here, but it doesn't know about test_match_signal.
Likewise, for tests which expect success (i.e., not SIGPIPE), we can
just put them in the &&-chain as usual. That even lets us get rid of the
!MINGW check, since the expectation is the same on both sides.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22 02:10:56 +03:00
|
|
|
{ test_terminal git log >/dev/null; OUT=$?; } &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_match_signal 13 "$OUT"
|
|
|
|
else
|
|
|
|
test_terminal git log
|
|
|
|
fi &&
|
2021-02-02 05:00:00 +03:00
|
|
|
|
|
|
|
grep child_exit trace.normal >child-exits &&
|
|
|
|
test_line_count = 1 child-exits &&
|
|
|
|
grep " code:143 " child-exits &&
|
2021-02-02 04:59:58 +03:00
|
|
|
test_path_is_file pager-used
|
|
|
|
'
|
|
|
|
|
pager: fix crash when pager program doesn't exist
When prepare_cmd() fails for, e.g., pager process setup,
child_process_clear() frees the memory in pager_process.args, but .argv
was pointed to pager_process.args.v earlier in start_command(), so it's
now a dangling pointer.
setup_pager() is then called a second time, from cmd_log_init_finish()
in this case, and any further operations using its .argv, e.g. strvec_*,
will use the dangling pointer and eventually crash. According to trivial
tests, setup_pager() is not called twice if the first call is
successful.
This patch makes sure that pager_process is properly initialized on
setup_pager(). Drop CHILD_PROCESS_INIT from its declaration since it's
no longer really necessary.
Add a test to catch possible regressions.
Reproducer:
$ git config pager.show INVALID_PAGER
$ git show $VALID_COMMIT
error: cannot run INVALID_PAGER: No such file or directory
[1] 3619 segmentation fault (core dumped) git show $VALID_COMMIT
Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-25 03:02:39 +03:00
|
|
|
test_expect_success TTY 'non-existent pager doesnt cause crash' '
|
|
|
|
test_config pager.show invalid-pager &&
|
|
|
|
test_terminal git show
|
|
|
|
'
|
|
|
|
|
2010-02-19 10:18:58 +03:00
|
|
|
test_done
|