# Re: git-diff should not fire up $PAGER, period!

3 messages from 2008-12-18 to 2008-12-18. Participants: Mike Coleman, Junio C Hamano, Johannes Schindelin.
Thread: https://gitlist.dev/t/16777

## Mike Coleman, 2008-12-18 02:18

Subject: Re: git-diff should not fire up $PAGER, period!
Message-ID: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com>
URL: https://gitlist.dev/e/3c6c07c20812171818k6b6e3555ja991e20d74d8291b%40mail.gmail.com

```
It's so cold here my car wouldn't start this morning, so I feel
fortunate to have these flames to keep me warm!  :-)


I still find git-diff's unsolicited invocation of $PAGER a bit
jarring, but I also find that I like it.  It has a sort of Windows-ish
feel to it (am I straying from the true path?).  It's convenient,
though honestly "git-diff|l" would only be two extra characters.  From
a UI perspective, the oddest thing about it is that all (not, in
fact?) of the other git programs which might also produce lengthy
output *don't* invoke $PAGER--git-status particularly comes to mind.
There are a large number of Unix programs that would be more
convenient if their output was automatically paged, but I'm not sure
it'd be better if they were all changed to do this.  (The best analog
I can think of where this seems desirable is man(1).)

To me, the most important nugget from the original complaint was that
git-diff sends its error messages to stdout.  I understand why it
might be done, but I'd worry about losing the stderr diagnostic for a
command that matters.  [I've been playing around with this for a few
minutes trying to see errors going to stdout and I can't reproduce
it--I wonder if they really do.]


Regarding the emacs complaint, as an emacs user I'd say I'm not
surprised this didn't quite work right.  In the particular case of the
compilation buffer, I wonder if the solution isn't to just unset TERM,
the existence of which (together with the fact that there's a pty)
could be taken as an invitation for the subordinate process to start
doing awful raw-terminal things.  (Similar logic applies to the
DISPLAY variable.)  Like Junio, I also eschew doing terminal emulation
inside of emacs.

Good evening from the icy midwest,
Mike

```

## Junio C Hamano, 2008-12-18 02:26

Subject: Re: git-diff should not fire up $PAGER, period!
Message-ID: <7vy6yei5ha.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vy6yei5ha.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com>

```
"Mike Coleman" <tutufan@gmail.com> writes:

> To me, the most important nugget from the original complaint was that
> git-diff sends its error messages to stdout.  I understand why it
> might be done, but I'd worry about losing the stderr diagnostic for a
> command that matters.  [I've been playing around with this for a few
> minutes trying to see errors going to stdout and I can't reproduce
> it--I wonder if they really do.]

They indeed did but it has hopefully been fixed.  See a833502 (pager: do
not dup2 stderr if it is already redirected, 2008-12-15).

> ...  Like Junio, I also eschew doing terminal emulation
> inside of emacs.

Come to think of it, it may have been from you that I picked up the trick
of setting PAGER to cat inside an Emacs environment.

> Good evening from the icy midwest,

Good evening from rainy and chilly SoCal.

```

## Johannes Schindelin, 2008-12-18 03:22

Subject: Re: git-diff should not fire up $PAGER, period!
Message-ID: <alpine.DEB.1.00.0812180419090.14632@racer>
URL: https://gitlist.dev/e/alpine.DEB.1.00.0812180419090.14632%40racer
In-Reply-To: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com>

```
Hi,

On Wed, 17 Dec 2008, Mike Coleman wrote:

> I still find git-diff's unsolicited invocation of $PAGER a bit
> jarring, but I also find that I like it.

It might have its reason in that it follows the common flow, where 
interactive use of _any_ diff program is _just useless_ unless piped to a 
pager.

And no, redirecting to a file is not interactive.

Can we please stop with those bogus and pointless, not to mention 
uninformed, discussions about design decisions that have been verified to 
be useful, or at least not harmful in any way, for a _long_, _long_ time?

The git list is high volume already, but at least so far it was high 
signal/noise ratio.

Let's keep it that way,
Dscho

```
