worley@xxxxxxxxxxxx (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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html