Junio C Hamano [off-list ref] writes:
I know $GIT_PAGER trumps core.pager, which indicates between
equivalents, environment is taken as a stronger wish. But I do not
mind if the order were updated to pager.<cmd> trumps $GIT_PAGER,
which in turn trumps core.pager, which in turn trumps $PAGER.
If such a precedence order makes it impossible to override a
configured pager.<cmd> value at runtime, then it is a bad idea. But
luckily, we can do
git -c "pager.<cmd>=<this one-shot pager>" cmd ...
to override a configured one, so perhaps it is OK.
I tend to agree with opinions I read elsewhere in this thread that
it would be better not to do the fallback in the first place, but
in this case, what I said I am OK with is when pager.<cmd> is
defined, we do not even look at $GIT_PAGER or later choices, which
is orthogonal.
On Mon, Nov 22, 2021 at 10:19:15AM -0800, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
I know $GIT_PAGER trumps core.pager, which indicates between
equivalents, environment is taken as a stronger wish. But I do not
mind if the order were updated to pager.<cmd> trumps $GIT_PAGER,
which in turn trumps core.pager, which in turn trumps $PAGER.
If such a precedence order makes it impossible to override a
configured pager.<cmd> value at runtime, then it is a bad idea. But
luckily, we can do
git -c "pager.<cmd>=<this one-shot pager>" cmd ...
to override a configured one, so perhaps it is OK.
I tend to agree with opinions I read elsewhere in this thread that
it would be better not to do the fallback in the first place, but
in this case, what I said I am OK with is when pager.<cmd> is
defined, we do not even look at $GIT_PAGER or later choices, which
is orthogonal.
FWIW, I also scratched my head while looking at this topic over seeing
$GIT_PAGER take precedence over a command-specific pager.
I do wonder if changing the override behavior would end up breaking some
scripted uses, though. E.g., imagine some program which does custom
markup of Git output, and ships with a wrapper script like:
$ cat pretty-git
#!/bin/sh
GIT_PAGER='markup-git-output | less' "$@"
$ pretty-git log -p
which would now behave differently if the user has pager.log set.
I dunno. That is perhaps a bit far-fetched. Most tools that I know of
like that (diff-highlight and diff-so-fancy) just tell you to set up
pager.log in the first place.
Just grepping around on GitHub, I don't see many uses, but this one[1] for
example might get confused:
export GIT_PAGER=cat # disable pager when running interactively
So I dunno. It is probably unlikely to have much fallout. On the other
hand, I kind of wonder if the benefit is worth changing now.
-Peff
[0] https://github.com/node-inspector/node-inspector/blob/79e01c049286374f86dd560742a614019c02402f/tools/git-changelog.sh#L38