Revert "Stop starting pager recursively"

This reverts commit 88e8f908f2b0c56f9ccf8134d8ff9f689af9cc84.

Caused a usability regression for me and foul language for my coworkers.

In particular, I commonly do a "git log", with results going through less, find a potentially interesting commit and execute "git show <commit>" from less. This used to show the patch in less and no longer does.

Manually typing "git show <commit> | less" works, but is annoying, wasting time and usually only done after seeing the mess from the simple invocation.

---
 pager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 0cc75a8eee32..53670a63a7ae 100644
@@ -64,7 +64,7 @@ void setup_pager(void)
 {
 	const char *pager = git_pager(isatty(1));
 
-	if (!pager || pager_in_use())
+	if (!pager)
 		return;
 
 	/*

1.9.1

Ping.

Jörn

--
People really ought to be forced to read their code aloud over the phone. That would rapidly improve the choice of identifiers.
-- Al Viro

How do you solve the problem that the commit you revert was solving? The commit you propose to revert says in its message:

git-column can be used as a pager for other git commands, something like this:

GIT_PAGER="git -p column --mode='dense color'" git -p branch

The problem with this is that "git -p column" also has $GIT_PAGER set so the pager runs itself again as another pager. The end result is an infinite loop of forking.

There's probably a solution, but you can't ignore the problem (or someone else will later try to solve the infinite loop and revert your commit, and so on ...).

Matthieu Moy
http://www-verimag.imag.fr/~moy/

Disclaimer: I never looked at git internals before this regression forced me to and am likely talking out of my arse.

One approach is "don't do that then". Someone explicitly changed the git pager to be git, which itself takes the git pager, etc. That is asking for infinite recursion and the original problem was that git gave the user exactly what they asked for.

A second option is to add a --pager (or rather --no-pager) option to the command line and allow the user to specify

    GIT_PAGER="git --no-pager -p column --mode='dense color'" git -p branch

A third option is to try to be smart and give the user what he wants, not what he asked for. If the pager happens to be git, unset $GIT_PAGER, $PAGER and somehow disable core.pager. Yeah, that will turn nasty rather quickly.

A fourth option is to set an environment variable for the pager process itself. Disable paging similar to the original patch, but make it conditional on we_are_the_pager(), not pager_in_use().

My preference is option four, but see disclaimer above.

Jörn

--
I've never met a human being who would want to read 17,000 pages of documentation, and if there was, I'd kill him to get him out of the gene pool.
-- Joseph Costello

[+cc Duy, whose patch this is]

I think we have "--no-pager" already. But the "-p" is turning _on_ the pager, so you could also just omit it. IOW, I really don't understand why the original command was not simply:

  GIT_PAGER="git column --mode='dense color'" git -p branch

The whole infinite loop that the original commit solved is caused by specifying the "-p". So it sounds like the right solution is "don't do that". Am I missing something useful that the "-p" does?

I wonder if perhaps the intent was that the user might have set "pager.column", in which case the use of the pager is implied. I still think that the right solution is to use "--no-pager" explicitly then. If the user is invoking git inside GIT_PAGER, it is up to them to save themselves from infinite recursion.

-Peff

My reading of this is that Duy wanted to let "-p" kick in to pass the columnized output, which could be more than a page long, thru the usual "less" or whatever pager.

[+cc Duy for real this time]

I thought that at first, too. But it doesn't work, because his patch actually _suppresses_ the pager. For example, something like:

  git config pager.column less
  git config pager.branch "git column --mode=dense"
  git branch

actively works without the original patch (and after Jörn's revert), but not with current git. However, you would not use "-p" there in any case, because it kicks in early and only respects $GIT_PAGER.

And I would also say that you are much better off there actually specifying your whole pipeline as a unit:

git config pager.branch "git column --mode=dense | less"

I do a similar thing where I have PAGER=less, but set pager.log to "diff-highlight | less". I tried at one point to have it chain automatically, but the setup is just too complicated (as we're seeing here), and it's not _that_ big a deal to explicitly pipe to the next pager in the sequence.

-Peff

The intent of the commit was "that is a stupid thing to do, but it's not so obvious from the first glance, do not freeze my system for my mistake". But if it stops an actual use case, then I agree it should be reverted.

--
Duy

Thanks for the explanation. I think we should just go with Jörn's patch as-is, then.

-Peff

----- Original Message -----

Agreed. At best, the commit message could be improved to explain the situation, but the patch itself is OK.

Matthieu Moy
http://www-verimag.imag.fr/~moy/

Or do you want me to resend with sob?

Jörn

--
Tough times don't last, but tough people do.
-- Nigerian proverb

Just the Sign-off is trivial enough that even this brainless patch-monkey^Wpanda should be able to handle. The part "The log message could be improved" is something you may be better equipped to, though.

I'll tentatively queue this; if you or anybody in the thread can proofread it to typofix it or give me a better phrasing, that would be very much appreciated.

Thanks.

-- >8 --
From: Jörn Engel <[email protected]>
Date: Mon, 21 Apr 2014 16:46:22 -0400
Subject: [PATCH] pager: do allow spawning pager recursively

This reverts commit 88e8f908f2b0c56f9ccf8134d8ff9f689af9cc84, which tried to allow

    GIT_PAGER="git -p column --mode='dense color'" git -p branch

and still wanted to avoid "git -p column" to invoke itself. However, this falls into "don't do that -p then" category.

In particular, inside "git log", with results going through less, a potentially interesting commit may be found and from there inside "less", the user may want to execute "git show <commit>". Before the commit being reverted, this used to show the patch in less but it no longer does.

---
 pager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 0cc75a8..53670a6 100644
@@ -64,7 +64,7 @@ void setup_pager(void)
 {
 	const char *pager = git_pager(isatty(1));
 
-	if (!pager || pager_in_use())
+	if (!pager)
 		return;
 
 	/*

2.0.0-rc1-219-gf8dda7a

Looks good to me. The next bamboo is on the house.

Jörn

--
Maintenance in other professions and of other articles is concerned with the return of the item to its original state; in Software, maintenance is concerned with moving an item away from its original state. -- Les Belady