On Fri, 9 Jul 2021 at 21:41, Junio C Hamano <gitster@xxxxxxxxx> 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
