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!
