> From: Junio C Hamano <gits...@pobox.com>
> > 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).
I've just discovered this bit of documentation. Within the git-var
manual page is this entry:
Text viewer for use by git commands (e.g., less). The value is
meant to be interpreted by the shell. The order of preference is
the $GIT_PAGER environment variable, then core.pager configuration,
then $PAGER, and then finally less.
This suggests that the ordering is GIT_PAGER > core.pager > PAGER >
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html