2010-02-19 08:18:58 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='Test automatic use of a pager.'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
2010-06-12 18:36:51 +02:00
|
|
|
. "$TEST_DIRECTORY"/lib-pager.sh
|
2010-10-16 20:36:56 +02:00
|
|
|
. "$TEST_DIRECTORY"/lib-terminal.sh
|
2010-02-19 08:18:58 +01:00
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
2010-10-03 22:00:14 +02:00
|
|
|
sane_unset GIT_PAGER GIT_PAGER_IN_USE &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_unconfig core.pager &&
|
2010-04-15 02:38:07 +02:00
|
|
|
|
|
|
|
PAGER="cat >paginated.out" &&
|
|
|
|
export PAGER &&
|
|
|
|
|
2010-02-19 08:18:58 +01:00
|
|
|
test_commit initial
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'some commands use a pager' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 09:50:25 +01:00
|
|
|
test_terminal git log &&
|
2010-02-19 08:18:58 +01:00
|
|
|
test -e paginated.out
|
|
|
|
'
|
|
|
|
|
2010-08-06 05:12:46 +02: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 03:14:05 +01:00
|
|
|
test_expect_success TTY 'LESS and LV envvars are set for pagination' '
|
|
|
|
(
|
|
|
|
sane_unset LESS LV &&
|
2014-01-30 17:42:32 +01:00
|
|
|
PAGER="env >pager-env.out; wc" &&
|
2014-01-07 03:14:05 +01:00
|
|
|
export PAGER &&
|
|
|
|
|
|
|
|
test_terminal git log
|
|
|
|
) &&
|
|
|
|
grep ^LESS= pager-env.out &&
|
|
|
|
grep ^LV= pager-env.out
|
|
|
|
'
|
|
|
|
|
2016-08-04 13:40:25 +02: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 &&
|
|
|
|
PATH="$(git --exec-path):$PATH" &&
|
|
|
|
export PATH &&
|
|
|
|
test_terminal sh -c ". git-sh-setup && git_pager"
|
|
|
|
) &&
|
|
|
|
grep ^LESS= pager-env.out &&
|
|
|
|
grep ^LV= pager-env.out
|
|
|
|
'
|
|
|
|
|
2010-02-19 08:18:58 +01:00
|
|
|
test_expect_success TTY 'some commands do not use a pager' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 09:50:25 +01:00
|
|
|
test_terminal git rev-list HEAD &&
|
2010-02-19 08:18:58 +01:00
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no pager when stdout is a pipe' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f paginated.out &&
|
2010-02-19 08:18:58 +01:00
|
|
|
git log | cat &&
|
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no pager when stdout is a regular file' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f paginated.out &&
|
2010-04-15 02:38:07 +02:00
|
|
|
git log >file &&
|
2010-02-19 08:18:58 +01:00
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git --paginate rev-list uses a pager' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 09:50:25 +01:00
|
|
|
test_terminal git --paginate rev-list HEAD &&
|
2010-02-19 08:18:58 +01:00
|
|
|
test -e paginated.out
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no pager even with --paginate when stdout is a pipe' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f file paginated.out &&
|
2010-02-19 08:18:58 +01:00
|
|
|
git --paginate log | cat &&
|
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'no pager with --no-pager' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f paginated.out &&
|
2010-02-20 09:50:25 +01:00
|
|
|
test_terminal git --no-pager log &&
|
2010-02-19 08:18:58 +01:00
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
2010-08-06 05:06:39 +02:00
|
|
|
test_expect_success TTY 'configuration can disable pager' '
|
|
|
|
rm -f paginated.out &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_unconfig pager.grep &&
|
2010-08-06 05:06:39 +02:00
|
|
|
test_terminal git grep initial &&
|
|
|
|
test -e paginated.out &&
|
|
|
|
|
|
|
|
rm -f paginated.out &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_config pager.grep false &&
|
2010-08-06 05:06:39 +02:00
|
|
|
test_terminal git grep initial &&
|
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
2010-08-16 10:08:34 +02:00
|
|
|
test_expect_success TTY 'configuration can enable pager (from subdir)' '
|
2010-08-06 05:12:46 +02:00
|
|
|
rm -f paginated.out &&
|
|
|
|
mkdir -p subdir &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_config pager.bundle true &&
|
2010-08-06 05:12:46 +02:00
|
|
|
|
|
|
|
git bundle create test.bundle --all &&
|
|
|
|
rm -f paginated.out subdir/paginated.out &&
|
|
|
|
(
|
|
|
|
cd subdir &&
|
|
|
|
test_terminal git bundle unbundle ../test.bundle
|
|
|
|
) &&
|
|
|
|
{
|
|
|
|
test -e paginated.out ||
|
|
|
|
test -e subdir/paginated.out
|
|
|
|
}
|
|
|
|
'
|
|
|
|
|
2017-08-02 21:40:54 +02: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 21:40:52 +02:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git tag -l &&
|
2017-08-02 21:40:54 +02:00
|
|
|
test -e 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 21:40:52 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag -l respects pager.tag' '
|
|
|
|
rm -f paginated.out &&
|
2017-08-02 21:40:54 +02:00
|
|
|
test_terminal git -c pager.tag=false tag -l &&
|
|
|
|
! test -e 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 21:40:52 +02: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 &&
|
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
2017-08-02 21:40:54 +02: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 21:40:52 +02:00
|
|
|
# no args implies -l so this should page like -l
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git tag &&
|
2017-08-02 21:40:54 +02:00
|
|
|
test -e 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 21:40:52 +02: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 21:40:54 +02:00
|
|
|
test_terminal git -c pager.tag=false tag &&
|
|
|
|
! test -e 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 21:40:52 +02:00
|
|
|
'
|
|
|
|
|
2017-08-02 21:40:54 +02: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 21:40:52 +02:00
|
|
|
# --contains implies -l so this should page like -l
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git tag --contains &&
|
2017-08-02 21:40:54 +02:00
|
|
|
test -e 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 21:40:52 +02: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 21:40:54 +02:00
|
|
|
test_terminal git -c pager.tag=false tag --contains &&
|
|
|
|
! test -e 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 21:40:52 +02: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 &&
|
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
2017-08-02 21:40:53 +02: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 21:40:52 +02:00
|
|
|
test_when_finished "git tag -d newtag" &&
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.tag tag -am message newtag &&
|
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
|
|
|
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 &&
|
|
|
|
test -e paginated.out
|
|
|
|
'
|
|
|
|
|
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 21:40:55 +02:00
|
|
|
test_expect_success TTY 'git tag as alias ignores pager.tag with -a' '
|
2017-08-02 21:40:53 +02: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 &&
|
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git tag as alias respects pager.tag with -l' '
|
|
|
|
rm -f paginated.out &&
|
2017-08-02 21:40:54 +02:00
|
|
|
test_terminal git -c pager.tag=false -c alias.t=tag t -l &&
|
|
|
|
! test -e paginated.out
|
2017-08-02 21:40:53 +02:00
|
|
|
'
|
|
|
|
|
2017-11-19 16:03:50 +01:00
|
|
|
test_expect_success TTY 'git branch defaults to paging' '
|
2017-11-19 16:03:48 +01:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git branch &&
|
2017-11-19 16:03:50 +01:00
|
|
|
test -e paginated.out
|
2017-11-19 16:03:48 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git branch respects pager.branch' '
|
|
|
|
rm -f paginated.out &&
|
2017-11-19 16:03:50 +01:00
|
|
|
test_terminal git -c pager.branch=false branch &&
|
|
|
|
! test -e paginated.out
|
2017-11-19 16:03:48 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git branch respects --no-pager' '
|
|
|
|
rm -f paginated.out &&
|
2017-11-19 16:03:50 +01:00
|
|
|
test_terminal git --no-pager branch &&
|
2017-11-19 16:03:48 +01:00
|
|
|
! test -e paginated.out
|
|
|
|
'
|
|
|
|
|
2017-11-19 16:03:49 +01:00
|
|
|
test_expect_success TTY 'git branch --edit-description ignores pager.branch' '
|
2017-11-19 16:03:48 +01: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 &&
|
|
|
|
! test -e paginated.out &&
|
|
|
|
test -e editor.used
|
|
|
|
'
|
|
|
|
|
2017-11-19 16:03:49 +01:00
|
|
|
test_expect_success TTY 'git branch --set-upstream-to ignores pager.branch' '
|
2017-11-19 16:03:48 +01: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" &&
|
2017-11-19 16:03:49 +01:00
|
|
|
! test -e paginated.out
|
2017-11-19 16:03:48 +01:00
|
|
|
'
|
|
|
|
|
2018-02-21 19:51:43 +01: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 19:51:42 +01:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.config config foo.bar bar &&
|
2018-02-21 19:51:43 +01:00
|
|
|
! test -e 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 19:51:42 +01:00
|
|
|
'
|
|
|
|
|
2018-02-21 19:51:43 +01: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 19:51:42 +01: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 &&
|
|
|
|
! test -e paginated.out &&
|
|
|
|
test -e editor.used
|
|
|
|
'
|
|
|
|
|
2018-02-21 19:51:43 +01: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 19:51:42 +01:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c pager.config config --get foo.bar &&
|
2018-02-21 19:51:43 +01:00
|
|
|
! test -e 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 19:51:42 +01:00
|
|
|
'
|
|
|
|
|
2018-02-21 19:51:44 +01: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 19:51:42 +01:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git -c http."https://foo.com/".bar=foo \
|
|
|
|
config --get-urlmatch http https://foo.com &&
|
2018-02-21 19:51:44 +01:00
|
|
|
test -e 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 19:51:42 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'git config --get-all respects pager.config' '
|
|
|
|
rm -f paginated.out &&
|
2018-02-21 19:51:44 +01:00
|
|
|
test_terminal git -c pager.config=false config --get-all foo.bar &&
|
|
|
|
! test -e 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 19:51:42 +01:00
|
|
|
'
|
|
|
|
|
2018-02-21 19:51:44 +01: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 19:51:42 +01:00
|
|
|
rm -f paginated.out &&
|
|
|
|
test_terminal git config --list &&
|
2018-02-21 19:51:44 +01:00
|
|
|
test -e 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 19:51:42 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
2010-02-19 08:18:58 +01: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 02:38:07 +02:00
|
|
|
read firstline <$1
|
2010-06-21 20:18:54 +02:00
|
|
|
! expr "$firstline" : "[a-zA-Z]" >/dev/null
|
2010-02-19 08:18:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success 'tests can detect color' '
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f colorful.log colorless.log &&
|
2010-04-15 02:38:07 +02:00
|
|
|
git log --no-color >colorless.log &&
|
|
|
|
git log --color >colorful.log &&
|
2010-02-19 08:18:58 +01:00
|
|
|
! colorful colorless.log &&
|
|
|
|
colorful colorful.log
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no color when stdout is a regular file' '
|
2010-04-15 02:38:07 +02:00
|
|
|
rm -f colorless.log &&
|
2011-12-14 09:22:03 +01:00
|
|
|
test_config color.ui auto &&
|
2010-04-15 02:38:07 +02:00
|
|
|
git log >colorless.log &&
|
2010-02-19 08:18:58 +01:00
|
|
|
! colorful colorless.log
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success TTY 'color when writing to a pager' '
|
2010-04-15 02:38:07 +02:00
|
|
|
rm -f paginated.out &&
|
2011-12-14 09:22:03 +01:00
|
|
|
test_config color.ui auto &&
|
2017-10-03 15:39:34 +02:00
|
|
|
test_terminal git log &&
|
2010-02-19 08:18:58 +01: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 07:04:23 +02:00
|
|
|
test_expect_success TTY 'colors are suppressed by color.pager' '
|
|
|
|
rm -f paginated.out &&
|
|
|
|
test_config color.ui auto &&
|
|
|
|
test_config color.pager false &&
|
2017-10-03 15:39:34 +02: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 07:04:23 +02:00
|
|
|
! colorful paginated.out
|
|
|
|
'
|
|
|
|
|
2010-02-19 08:18:58 +01:00
|
|
|
test_expect_success 'color when writing to a file intended for a pager' '
|
2010-04-15 02:38:07 +02:00
|
|
|
rm -f colorful.log &&
|
2011-12-14 09:22:03 +01:00
|
|
|
test_config color.ui auto &&
|
2010-04-15 02:38:07 +02:00
|
|
|
(
|
|
|
|
TERM=vt100 &&
|
|
|
|
GIT_PAGER_IN_USE=true &&
|
|
|
|
export TERM GIT_PAGER_IN_USE &&
|
|
|
|
git log >colorful.log
|
|
|
|
) &&
|
2010-02-19 08:18:58 +01:00
|
|
|
colorful colorful.log
|
|
|
|
'
|
|
|
|
|
2011-08-18 07:02:29 +02: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 15:39:34 +02:00
|
|
|
test_terminal git -p externallog &&
|
2011-08-18 07:02:29 +02:00
|
|
|
colorful paginated.out
|
|
|
|
'
|
|
|
|
|
2010-06-26 21:23:02 +02: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 02:38:07 +02:00
|
|
|
|
2010-06-26 21:24:50 +02:00
|
|
|
test_default_pager() {
|
|
|
|
parse_args "$@"
|
|
|
|
|
2010-10-16 20:36:59 +02:00
|
|
|
$test_expectation SIMPLEPAGER,TTY "$cmd - default pager is used by default" "
|
2010-10-03 22:00:14 +02:00
|
|
|
sane_unset PAGER GIT_PAGER &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_unconfig core.pager &&
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f default_pager_used &&
|
2010-06-26 21:24:50 +02:00
|
|
|
cat >\$less <<-\EOF &&
|
|
|
|
#!/bin/sh
|
|
|
|
wc >default_pager_used
|
|
|
|
EOF
|
|
|
|
chmod +x \$less &&
|
|
|
|
(
|
|
|
|
PATH=.:\$PATH &&
|
|
|
|
export PATH &&
|
|
|
|
$full_command
|
|
|
|
) &&
|
|
|
|
test -e default_pager_used
|
|
|
|
"
|
|
|
|
}
|
2010-02-19 08:18:58 +01:00
|
|
|
|
2010-06-26 21:24:50 +02:00
|
|
|
test_PAGER_overrides() {
|
|
|
|
parse_args "$@"
|
2010-04-15 02:38:07 +02:00
|
|
|
|
2010-06-26 21:24:50 +02:00
|
|
|
$test_expectation TTY "$cmd - PAGER overrides default pager" "
|
2010-10-03 22:00:14 +02:00
|
|
|
sane_unset GIT_PAGER &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_unconfig core.pager &&
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f PAGER_used &&
|
2010-06-26 21:24:50 +02:00
|
|
|
PAGER='wc >PAGER_used' &&
|
|
|
|
export PAGER &&
|
|
|
|
$full_command &&
|
|
|
|
test -e PAGER_used
|
|
|
|
"
|
|
|
|
}
|
2010-04-15 02:38:07 +02:00
|
|
|
|
2010-06-26 21:24:50 +02: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 21:26:37 +02:00
|
|
|
if_local_config=
|
|
|
|
used_if_wanted='overrides PAGER'
|
|
|
|
test_core_pager "$@"
|
|
|
|
}
|
2010-02-19 08:18:58 +01: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 21:26:37 +02:00
|
|
|
test_local_config_ignored() {
|
|
|
|
if_local_config='! '
|
|
|
|
used_if_wanted='is not used'
|
|
|
|
test_core_pager "$@"
|
|
|
|
}
|
2010-04-15 02:38:07 +02: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 21:26:37 +02:00
|
|
|
test_core_pager() {
|
2010-06-26 21:24:50 +02: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 21:26:37 +02:00
|
|
|
$test_expectation TTY "$cmd - repository-local core.pager setting $used_if_wanted" "
|
2010-10-03 22:00:14 +02:00
|
|
|
sane_unset GIT_PAGER &&
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f core.pager_used &&
|
2010-06-26 21:24:50 +02:00
|
|
|
PAGER=wc &&
|
|
|
|
export PAGER &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_config core.pager 'wc >core.pager_used' &&
|
2010-06-26 21:24:50 +02:00
|
|
|
$full_command &&
|
git --paginate: do not commit pager choice too early
When git is passed the --paginate option, starting up a pager requires
deciding what pager to start, which requires access to the core.pager
configuration.
At the relevant moment, the repository has not been searched for yet.
Attempting to access the configuration at this point results in
git_dir being set to .git [*], which is almost certainly not what was
wanted. In particular, when run from a subdirectory of the toplevel,
git --paginate does not respect the core.pager setting from the
current repository.
[*] unless GIT_DIR or GIT_CONFIG is set
So delay the pager startup when possible:
1. run_argv() already commits pager choice inside run_builtin() if a
command is found. For commands that use RUN_SETUP, waiting until
then fixes the problem described above: once git knows where to
look, it happily respects the core.pager setting.
2. list_common_cmds_help() prints out 29 lines and exits. This can
benefit from pagination, so we need to commit the pager choice
before writing this output.
Luckily ‘git’ without subcommand has no other reason to access a
repository, so it would be intuitive to ignore repository-local
configuration in this case. Simpler for now to choose a pager
using the funny code that notices a repository that happens to be
at .git. That this accesses a repository when it is very
convenient to is a bug but not an important one.
3. help_unknown_cmd() prints out a few lines to stderr. It is not
important to paginate this, so don’t.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
|
|
|
${if_local_config}test -e core.pager_used
|
2010-06-26 21:24:50 +02:00
|
|
|
"
|
|
|
|
}
|
|
|
|
|
2010-06-26 21:25:37 +02: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 21:26:37 +02:00
|
|
|
if_local_config=
|
|
|
|
used_if_wanted='overrides PAGER'
|
|
|
|
test_pager_subdir_helper "$@"
|
|
|
|
}
|
|
|
|
|
|
|
|
test_no_local_config_subdir() {
|
|
|
|
if_local_config='! '
|
|
|
|
used_if_wanted='is not used'
|
|
|
|
test_pager_subdir_helper "$@"
|
|
|
|
}
|
|
|
|
|
|
|
|
test_pager_subdir_helper() {
|
2010-06-26 21:25:37 +02: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 21:26:37 +02:00
|
|
|
$test_expectation TTY "$cmd - core.pager $used_if_wanted from subdirectory" "
|
2010-10-03 22:00:14 +02:00
|
|
|
sane_unset GIT_PAGER &&
|
2010-06-26 21:25:37 +02:00
|
|
|
rm -f core.pager_used &&
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -fr sub &&
|
2010-06-26 21:25:37 +02:00
|
|
|
PAGER=wc &&
|
|
|
|
stampname=\$(pwd)/core.pager_used &&
|
|
|
|
export PAGER stampname &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_config core.pager 'wc >\"\$stampname\"' &&
|
2010-06-26 21:25:37 +02:00
|
|
|
mkdir sub &&
|
|
|
|
(
|
|
|
|
cd sub &&
|
|
|
|
$full_command
|
|
|
|
) &&
|
git --paginate: do not commit pager choice too early
When git is passed the --paginate option, starting up a pager requires
deciding what pager to start, which requires access to the core.pager
configuration.
At the relevant moment, the repository has not been searched for yet.
Attempting to access the configuration at this point results in
git_dir being set to .git [*], which is almost certainly not what was
wanted. In particular, when run from a subdirectory of the toplevel,
git --paginate does not respect the core.pager setting from the
current repository.
[*] unless GIT_DIR or GIT_CONFIG is set
So delay the pager startup when possible:
1. run_argv() already commits pager choice inside run_builtin() if a
command is found. For commands that use RUN_SETUP, waiting until
then fixes the problem described above: once git knows where to
look, it happily respects the core.pager setting.
2. list_common_cmds_help() prints out 29 lines and exits. This can
benefit from pagination, so we need to commit the pager choice
before writing this output.
Luckily ‘git’ without subcommand has no other reason to access a
repository, so it would be intuitive to ignore repository-local
configuration in this case. Simpler for now to choose a pager
using the funny code that notices a repository that happens to be
at .git. That this accesses a repository when it is very
convenient to is a bug but not an important one.
3. help_unknown_cmd() prints out a few lines to stderr. It is not
important to paginate this, so don’t.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-26 21:26:37 +02:00
|
|
|
${if_local_config}test -e core.pager_used
|
2010-06-26 21:25:37 +02:00
|
|
|
"
|
|
|
|
}
|
|
|
|
|
2010-06-26 21:24:50 +02:00
|
|
|
test_GIT_PAGER_overrides() {
|
|
|
|
parse_args "$@"
|
|
|
|
|
|
|
|
$test_expectation TTY "$cmd - GIT_PAGER overrides core.pager" "
|
2011-12-14 09:22:03 +01:00
|
|
|
rm -f GIT_PAGER_used &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_config core.pager wc &&
|
2010-06-26 21:24:50 +02:00
|
|
|
GIT_PAGER='wc >GIT_PAGER_used' &&
|
|
|
|
export GIT_PAGER &&
|
|
|
|
$full_command &&
|
|
|
|
test -e GIT_PAGER_used
|
|
|
|
"
|
|
|
|
}
|
2010-04-15 02:38:07 +02: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 21:26:37 +02:00
|
|
|
test_doesnt_paginate() {
|
|
|
|
parse_args "$@"
|
|
|
|
|
|
|
|
$test_expectation TTY "no pager for '$cmd'" "
|
2011-12-14 09:22:03 +01: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 21:26:37 +02:00
|
|
|
GIT_PAGER='wc >GIT_PAGER_used' &&
|
|
|
|
export GIT_PAGER &&
|
|
|
|
$full_command &&
|
|
|
|
! test -e GIT_PAGER_used
|
|
|
|
"
|
|
|
|
}
|
|
|
|
|
2010-07-15 00:55:12 +02: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 08:18:58 +01:00
|
|
|
'
|
|
|
|
|
2010-07-15 00:55:12 +02: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 21:11:12 +01:00
|
|
|
test_core_pager_subdir expect_success 'git -p aliasedlog'
|
2010-07-15 00:55:12 +02: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 21:11:12 +01:00
|
|
|
test_core_pager_subdir expect_success 'git -p true'
|
2010-07-15 00:55:12 +02: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 21:11:12 +01:00
|
|
|
test_core_pager_subdir expect_success test_must_fail 'git -p request-pull'
|
2010-07-15 00:55:12 +02:00
|
|
|
test_GIT_PAGER_overrides expect_success test_must_fail 'git -p request-pull'
|
2010-06-26 21:24:50 +02: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 21:26:37 +02:00
|
|
|
test_local_config_ignored expect_failure test_must_fail 'git -p'
|
2010-06-26 21:24:50 +02:00
|
|
|
test_GIT_PAGER_overrides expect_success test_must_fail 'git -p'
|
|
|
|
|
2017-03-13 21:11:12 +01: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 18:32:01 +01: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 13:36:00 +02:00
|
|
|
test_expect_success TTY 'core.pager is found via alias in subdirectory' '
|
2017-06-14 13:35:56 +02: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 00:55:12 +02:00
|
|
|
test_doesnt_paginate expect_failure test_must_fail 'git -p nonsense'
|
2010-02-19 08:18:58 +01:00
|
|
|
|
2010-08-06 05:01:37 +02: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 02:36:12 +02:00
|
|
|
test_core_pager_subdir expect_success test_must_fail \
|
|
|
|
'git -p apply </dev/null'
|
|
|
|
|
2010-11-17 18:04:12 +01:00
|
|
|
test_expect_success TTY 'command-specific pager' '
|
2011-08-18 07:00:47 +02:00
|
|
|
sane_unset PAGER GIT_PAGER &&
|
2010-11-17 18:04:12 +01:00
|
|
|
echo "foo:initial" >expect &&
|
|
|
|
>actual &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_unconfig core.pager &&
|
|
|
|
test_config pager.log "sed s/^/foo:/ >actual" &&
|
2010-11-17 18:04:12 +01: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 07:00:47 +02:00
|
|
|
sane_unset PAGER GIT_PAGER &&
|
2010-11-17 18:04:12 +01:00
|
|
|
echo "foo:initial" >expect &&
|
|
|
|
>actual &&
|
2015-03-20 11:07:15 +01:00
|
|
|
test_config core.pager "exit 1" &&
|
2011-08-18 07:02:06 +02:00
|
|
|
test_config pager.log "sed s/^/foo:/ >actual" &&
|
2010-11-17 18:04:12 +01: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 07:02:06 +02:00
|
|
|
test_config pager.log "exit 1" &&
|
2010-11-17 18:04:12 +01:00
|
|
|
test_terminal git log --format=%s -1 &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2011-08-19 00:01:32 +02: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 14:51:50 +01:00
|
|
|
test_terminal git --exec-path="$(pwd)" external log --format=%s -1 &&
|
2011-08-19 00:01:32 +02: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 19:48:11 +02:00
|
|
|
test_must_be_empty actual
|
2011-08-19 00:01:32 +02: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 08:11:33 +02:00
|
|
|
test_expect_success 'command with underscores does not complain' '
|
|
|
|
write_script git-under_score <<-\EOF &&
|
|
|
|
echo ok
|
|
|
|
EOF
|
|
|
|
git --exec-path=. under_score >actual 2>&1 &&
|
|
|
|
echo ok >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2017-10-16 20:35:11 +02: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
|
|
|
|
'
|
|
|
|
|
2010-02-19 08:18:58 +01:00
|
|
|
test_done
|