Enzo Matsumiya <ematsumiya@xxxxxxx> writes: > However, IMHO it would make sense to try pager.<subcommand> if a > previous attempt failed, e.g.: > > $ git config pager.show my-valid-pager > $ GIT_PAGER=invalid-pager git -p show > > So this will first try invalid-pager, fail, and not try again, with the > above patch. As a user, I would expect that my-valid-pager to be run in > case invalid-pager failed. > > What do you think? Interesting. As presented here, it makes it look as if the user is trying to override configured values for this particular invocation, which would mean the environment must win (i.e. we should ignore pager.<cmd> and only pay attention to GIT_PAGER), but if we consider the way envionment is normally used, that is a faulty logic. Just like configuration variables are to set the value that the user normally uses unless overridden, environment variables are the same way. 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.
