All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: worley@alum.mit.edu (Dale R. Worley)
Cc: git@vger.kernel.org
Subject: Re: the pager
Date: Mon, 26 Aug 2013 21:38:28 -0700	[thread overview]
Message-ID: <xmqqd2ozhhob.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <201308261957.r7QJvfjF028935@freeze.ariadne.com> (Dale R. Worley's message of "Mon, 26 Aug 2013 15:57:41 -0400")

worley@alum.mit.edu (Dale R. Worley) writes:

> 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")
> ...
> What is the (intended) order of precedence of specifiers of paging
> behavior?  My guess is that it should be the order I've given above.

I think that sounds about right (I didn't check the code, though).
The most specific to the command line invocation (i.e. option)
trumps the environment, which trumps the configured default, and the
hard wired stuff is used as the fallback default.

I am not sure about PAGER environment and core.pager, though.
People want Git specific pager that applies only to Git process
specified to core.pager, and still want to use their own generic
PAGER to other programs, so my gut feeling is that it would make
sense to consider core.pager a way to specify GIT_PAGER without
contaminating the environment, and use both to override the generic
PAGER (in other words, core.pager should take precedence over PAGER
as far as Git is concerned).

  reply	other threads:[~2013-08-27  4:38 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 [this message]
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

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=xmqqd2ozhhob.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.