From: Jeff King <peff@peff.net>
To: "Dale R. Worley" <worley@alum.mit.edu>
Cc: git@vger.kernel.org
Subject: Re: the pager
Date: Tue, 3 Sep 2013 04:01:19 -0400 [thread overview]
Message-ID: <20130903080119.GF3608@sigill.intra.peff.net> (raw)
In-Reply-To: <201309030237.r832bjZp014060@freeze.ariadne.com>
On Mon, Sep 02, 2013 at 10:37:45PM -0400, Dale R. Worley wrote:
> > I've noticed that Git by default puts long output through "less" as a
> > pager. I don't like that, but this is not the time to change
> > established behavior. But while tracking that down, I noticed that
> > the paging behavior is controlled by at least 5 things:
> >
> > the -p/--paginate/--no-pager options
> > the GIT_PAGER environment variable
> > the PAGER environment variable
> > the core.pager Git configuration variable
> > the build-in default (which seems to usually be "less")
This list has some orthogonal concepts. The "-p" and "--no-pager"
variables decide _whether_ to run the pager. The GIT_PAGER and PAGER
environment variables, along with core.pager and the compile-time
default, decide _which_ pager to run.
The fact that "cat" or the empty string becomes "no pager" is purely an
optimization (we could fork and run "sh -c ''" or "cat", but it would be
a no-op). So even though you might have instructed git to run the pager,
it may be a noop if your pager is "cat", and we optimize it out.
The confusing one (and missing from your list) is pager.$program, which
originally was a "whether", but later learned to optionally be a
"which". And you also omit the built-in defaults for "whether" on each
command (e.g., "log" runs a pager, "push" does not).
> There is a somewhat independent question of when the pager is
> activated. What I know so far is that some commands use the pager by
> default and some by default do not. My expectation is that
> --no-pager can be used to suppress the pager for *any* command. Is it
> also true that -p can force the pager for *any* command, or are there
> commands which will not page even with -p?
Yes, --no-pager and -p suppress or force, respectively, for any command.
They take precedence over config (pager.$command), which in turn takes
precedence over builtin defaults (per-command defaults, in this case).
Environment variables should generally be less than command-line
options, but greater than config. But there is no "definitely use a
pager" environment variable, so it doesn't apply here.
And I say generally because we should put git-specific environment
variables over git-specific config, but git-specific config over general
environment variables (so similarly we should respect user.email in the
config over $EMAIL in the environment, but under $GIT_COMMITTER_EMAIL).
> I assume that if -p is specified but the "which pager" selection is
> "cat" (or some other specification of no pager), then there is no
> paging operation.
There is a pager in that case, but it doesn't do anything. And then we
optimize it out because it doesn't do anything. :) That is somewhat
tongue-in-cheek, but I hope it shows the mental model that goes into the
decision.
-Peff
prev parent reply other threads:[~2013-09-03 8:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-26 19:57 the pager Dale R. Worley
2013-08-27 4:38 ` Junio C Hamano
2013-08-28 18:19 ` Dale R. Worley
2013-08-28 20:26 ` Junio C Hamano
2013-08-29 15:41 ` Dale R. Worley
2013-08-29 15:55 ` Matthieu Moy
2013-09-03 2:27 ` Dale R. Worley
2013-09-03 2:57 ` Jonathan Nieder
2013-09-03 7:41 ` [PATCH] pager: turn on "cat" optimization for DEFAULT_PAGER Jeff King
2013-09-03 17:35 ` Junio C Hamano
2013-11-20 17:24 ` Erik Faye-Lund
2013-11-20 17:30 ` Jeff King
2013-11-20 17:33 ` Erik Faye-Lund
2013-11-20 17:33 ` Junio C Hamano
2013-11-20 17:34 ` Erik Faye-Lund
2013-09-03 8:16 ` the pager Jeff King
2013-09-03 2:37 ` Dale R. Worley
2013-09-03 8:01 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130903080119.GF3608@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=worley@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).