# format-patch with pager.format-patch=true gets very confused

3 messages from 2016-07-17 to 2016-07-17. Participants: Josh Triplett, Johannes Schindelin.
Thread: https://gitlist.dev/t/42865

## Josh Triplett, 2016-07-17 02:56

Subject: format-patch with pager.format-patch=true gets very confused
Message-ID: <20160717025642.GA30640@x>
URL: https://gitlist.dev/e/20160717025642.GA30640%40x

```
git-config(1) documents the ability to enable or disable the pager (or
set a command-specific pager) for any command by setting
pager.<cmd>=true.  For most commands, this seems to work as expected.
However, setting pager.format-patch=true (or setting it to any specific
pager) breaks badly: the pager spawns, with no output in it, and the
pager doesn't respond to keystrokes (which makes it difficult to quit).

I think this may occur because format-patch's "reopen_stdout" interacts
badly with the pager.

I think it makes sense for "format-patch --stdout" to respect
pager.format-patch, but for format-patch *without* stdout to ignore
pager.* and *never* spawn a pager, given that its only output (the list
of patch files) goes to "realstdout".

- Josh Triplett

```

## Johannes Schindelin, 2016-07-17 12:41

Subject: Re: format-patch with pager.format-patch=true gets very confused
Message-ID: <alpine.DEB.2.20.1607171438030.28832@virtualbox>
URL: https://gitlist.dev/e/alpine.DEB.2.20.1607171438030.28832%40virtualbox
In-Reply-To: <20160717025642.GA30640@x>

```
Hi Josh,

On Sat, 16 Jul 2016, Josh Triplett wrote:

> git-config(1) documents the ability to enable or disable the pager (or
> set a command-specific pager) for any command by setting
> pager.<cmd>=true.  For most commands, this seems to work as expected.
> However, setting pager.format-patch=true (or setting it to any specific
> pager) breaks badly: the pager spawns, with no output in it, and the
> pager doesn't respond to keystrokes (which makes it difficult to quit).
> 
> I think this may occur because format-patch's "reopen_stdout" interacts
> badly with the pager.
> 
> I think it makes sense for "format-patch --stdout" to respect
> pager.format-patch, but for format-patch *without* stdout to ignore
> pager.* and *never* spawn a pager, given that its only output (the list
> of patch files) goes to "realstdout".

As per http://article.gmane.org/gmane.comp.version-control.git/299451,
the `js/log-to-diffopt-file` patch series will be merged to `master` soon.
This patch series avoids the reopen() altogether and should fix the
problem you experience.

Since it is already in `next`, it should be relatively easy for you to
build and confirm. Would you kindly do that?

Thanks,
Johannes

```

## Josh Triplett, 2016-07-17 19:20

Subject: Re: format-patch with pager.format-patch=true gets very confused
Message-ID: <20160717192019.GA29262@x>
URL: https://gitlist.dev/e/20160717192019.GA29262%40x
In-Reply-To: <alpine.DEB.2.20.1607171438030.28832@virtualbox>

```
On Sun, Jul 17, 2016 at 02:41:48PM +0200, Johannes Schindelin wrote:
> Hi Josh,
> 
> On Sat, 16 Jul 2016, Josh Triplett wrote:
> 
> > git-config(1) documents the ability to enable or disable the pager (or
> > set a command-specific pager) for any command by setting
> > pager.<cmd>=true.  For most commands, this seems to work as expected.
> > However, setting pager.format-patch=true (or setting it to any specific
> > pager) breaks badly: the pager spawns, with no output in it, and the
> > pager doesn't respond to keystrokes (which makes it difficult to quit).
> > 
> > I think this may occur because format-patch's "reopen_stdout" interacts
> > badly with the pager.
> > 
> > I think it makes sense for "format-patch --stdout" to respect
> > pager.format-patch, but for format-patch *without* stdout to ignore
> > pager.* and *never* spawn a pager, given that its only output (the list
> > of patch files) goes to "realstdout".
> 
> As per http://article.gmane.org/gmane.comp.version-control.git/299451,
> the `js/log-to-diffopt-file` patch series will be merged to `master` soon.
> This patch series avoids the reopen() altogether and should fix the
> problem you experience.
> 
> Since it is already in `next`, it should be relatively easy for you to
> build and confirm. Would you kindly do that?

I can confirm that that fixes the problem.  Thanks!

- Josh Triplett

```