Re: git status in clean working dir

[Jeff King <peff@peff.net>]

On Tue, Jul 22, 2008 at 02:17:43AM -0700, Junio C Hamano wrote:

> Another slight worry I have is if the now-parent git process does the
> right thing when the user kills the pager without viewing the output to
> the end.  git itself will get stuck with write() while the user is
> reading, and then notice that the pipe does not have any more reader when
> the pager is killed.  This fact itself won't change by swapping the
> parent-child relationship, but would we get a sensible behaviour after
> that, or have we been ignoring what happens afterwards only because our
> exit status has been hidden behind the pager?  Running "git log" and
> killing it by "q" (my pager is "less") makes it exit with 141.

Hmm, good point. Though previously in this case, we were getting
whatever code the pager provided. Which means nobody probably cared that
much. Though I suppose that people who use "$?" in their prompt might
see scariness.

> I shouldn't worry, if everything is written correctly in the other parts
> of the system, this swap should not have much ill effect.

I am a little unhappy about the git process hanging around, but I don't
know if it is worth making a meta-process just to manage the pager.

Also, I think people with a pager that has spaces in in it will now need
to quote it (e.g., PAGER="/path with space/less" used to work, but now
is passed to the shell). Arguably, this brings it in line with other
spawned programs, like EDITOR, but it is a difference, and we are in
release freeze. That could be fixed with some magic in run_command.
(Note that it has always been run by the shell under Windows, so again,
this is making things more consistent).

> By the way [2/2] was not signed-off.  Just forgotten?

Yes, forgotten. If you are planning on applying, please forge (and
squash the portability fix).

-Peff