Avishay Matayev [off-list ref] writes:
quoted
quoted
If you don't find the approach in this patch good enough, what exactly
do you suggest?
Start with not tying this feature with the word "TTY", probably.
Well then, what are other indicators of 'interactivity' besides "TTY"?
If we want to force output to always go through the pager, we should
call it "force pager", not "force tty". If we want to always show
progress bar no matter where the output goes, we should call it
"force progress", not "force tty". These should be controllable
independenty, even though it is OK to have catch all "force
everything" for convenience.
There is no inherent reason why the output has to be passed through
the pager when it goes to tty. It merely is how we happen to have
designed the heuristics. We don't want to carve it in stone and
expose it on end-users with a poorly chosen name. Also, we do not
want to tie multiple features unnecessarily.
On Fri, 9 Jul 2021 at 21:41, Junio C Hamano [off-list ref] wrote:
If we want to force output to always go through the pager, we should
call it "force pager", not "force tty". If we want to always show
progress bar no matter where the output goes, we should call it
"force progress", not "force tty". These should be controllable
independenty, even though it is OK to have catch all "force
everything" for convenience.
But using "force pager" or "force progress" is exactly the same as
acknowledging that git uses tty for the output, as you'd have to know
that the pager wouldn't open because there is no tty. The original
implementation should've been to implement just the "force pager"
logic but we've realised there are more places where git acts in a
different way because of tty and I don't really see a reason those
should be controlled individually, it will just create too many variables
when the reason for their existence is the same, the absence of a tty.
There is no inherent reason why the output has to be passed through
the pager when it goes to tty. It merely is how we happen to have
designed the heuristics. We don't want to carve it in stone and
expose it on end-users with a poorly chosen name. Also, we do not
want to tie multiple features unnecessarily.
I mean, git is pretty CLI centered, it isn't a library, so I'd say there is a
pretty strong core reason for this design (at least that's how I see git).
Unfortunately, when we want to use git in its not really CLI-like way, it acts
unexpectedly.
Moreover, I really don't think this feature is intended for the
regular git user,
it will mostly help Fugitive or other programs that are built upon git's core,
and those are most likely have to be familiar with git's implementation in
one way or another.
Avishay