diff options
author | Martin Ågren <martin.agren@gmail.com> | 2017-08-02 21:40:55 +0200 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-08-03 11:08:11 -0700 |
commit | 595d59e2b53a19f8c5c277348e4e1a07bb913ba4 (patch) | |
tree | 7d2ec5731d65cc698c51c84c8c05e6d2d9fca0ce /builtin/gc.c | |
parent | ff1e72483f416ecb58737205163031f54c24e754 (diff) | |
download | git-595d59e2b53a19f8c5c277348e4e1a07bb913ba4.tar.gz |
git.c: ignore pager.* when launching builtin as dashed externalma/pager-per-subcommand-action
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>
Diffstat (limited to 'builtin/gc.c')
0 files changed, 0 insertions, 0 deletions