On 2024-05-21 00:35, Rubén Justo wrote:
On Mon, May 20, 2024 at 09:45:51PM +0200, Dragan Simic wrote:
Thus, if someone wants to have a complete longer-than-one-screen hunk
displayed and use the terminal emulator scrollback to inspect the
hunk in its entirety, passing such (or all) hunks through the pager
would make such inspection impossible. I'd assume that at least some
Git users already do that (I do, for example), and we surely don't
want
to make that no longer possible.
I'm not sure if I understand the problem... disabling the pager is
still an option, no?
$ git -P add -p
$ git -c pager.add=false add -p
Please read the thread [1] that I linked in my previous response
carefully.
I know, there's _a lot_ of text, but I already tried to sum it all up in
my
previous response. There's even a video clip [2] in that thread that
shows
the issue with the corrupted scrollback in a terminal emulator.
Frankly, the "-c pager.add=false" approach is a bit cumbersome.
Basically,
the new "-P" option would be like "-c pager.add=true", while the already
existing "-p" option would be like "-c pager.add=false". Though, I
think
that we don't want to add "pager.add" as a new configuration option,
because
throwing it into the mix would make the "-p" and "-P" options for "git
add"
quite confusing.
As another idea, we might also add "p" as another option in the
"y/n/q/a/d..."
menu when the user decides about each hunk in "git add -p" or "git add
-P".
When running "git add -p", pressing "p" would display the current hunk
using
the pager (which would be opposite to the "git add -p"'s behavior of not
using the pager), and when running "git add -P", pressing "p" would
display
the current hunk by bypassing the pager (again, opposite to the "add
-P"'s
behavior). That would allow greatest level of flexibility.
[1]
https://lore.kernel.org/git/8289ef15266172cbfa10bb146afe9797@xxxxxxxxxxx/T/#u
[2] https://youtu.be/MsxtQgrKM50
