Re: [PATCH] git: fix paginate handling for commands with DELAY_PAGER_CONFIG

["Matthew Bystrin" <dev.mbstr@gmail.com>]

Martin Ågren wrote:
> If `git add -p` is a long-running process that wants to repeatedly
> launch a pager, what could the opposite look like? A long-running
> process that wants to repeatedly launch an editor? While paging?
>
> Maybe `git rebase -i` could be one such example. TBH, running its output
> through a pager might not look super-pretty today due to it producing
> temporary output that it then erases, but at least it works. The editor
> might be graphical (or a script?) that won't actually suffer from the
> pager running. Killing the pager might be unwanted. So I don't know.

Agree, killing might be unwanted. Another approach proposed below.

> What is the original problem here? Is some kind of tooling issuing a
> `git -p tag -a` where it's not possible to teach it to drop the `-p`?

I faced such 'wrong' behaviour by typing commands manually.

It feels like one flag should not break execution of interactive commands like
`git -p add -p`, `git -p rebase -i`, `git -p config -e` etc. I took into account
Junio's comments, so please let me describe situation in more correct way. The
following is related with workflow in terminal.

Currently when some interactive command is called with `--paginate` I see
interfered output and cannot proceed to desirable actions. A good analogy is to
call `vim | less`.

What I want to see is if we are calling interactive command with
`--paginate` (1) it would rather fail explicitly with an error message, or (2)
it would close+reopen/bypass pager when some interaction is needed. Bypassing
pager is a complicated thing, I'm not sure it can be done (because of how they
claim stdin)

Of course we can just simply do not use `-p` flag with interactive commands and
provide some info in documentation.

Thanks!