On Tue, Sep 07 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >>> No, they need to know to call 'git var GIT_PAGER' rather than using >>> the environment variable directly to pick up core.pager[...] >> >> Sorry, I should have said "...directly via git var GIT_PAGER". I also >> see that we could improve some of the doc cross-referencing here, >> i.e. "git help git") doesn't make this explicit or point to "git var", >> but we cover this in "git help var" itself. >> >>> [...]should be checking whether stdout is a tty. That is why this function >>> existed and we didn't just check the value of GIT_PAGER in our scripts >> >> For a hypothetical out-of-tree user is this really something anyone >> strictly needs? It's just an optimization. If you don't do it you'll >> just use your pager to pipe output to a non-tty. > > The question we should be asking when we advocate to remove things > is "is this really something we absolutely cannot live with?" > > But answering your question, if an out-of-tree user wants to behave > just like Git, pretending that it would have been part of Git and > the only reason why it is not is because it weren't invented here, > yes, not forcing the end-user to pipe the tool's output to pager is > something they would want to have a handy way to mimic, I would > think. I've made my preferences clear, but can live with whatever criteria we come up with. I am having trouble squaring the desire to keep git_pager() with the view you're describing, unless it's also an implicit endorsement of reverting a89a2fbfccd (parse-remote: remove this now-unused library, 2020-11-14). I'd obviously prefer to see git-parse-remote stay gone. But if we're worried about removing once-documented "git-sh-*" libraries from under users who peeked under the hood at some point to see & use functions within them, I'd think bringing back "git-parse-remote" would be more likely to help those users than having a git_pager(). And once we're rid of all our own use of these libraries but still want to ship them forever for such users, I'd think we'd want to bring some version of a revert of 49eb8d39c78 (Remove contrib/examples/*, 2018-03-25) back, i.e. just to make sure we don't break these going forward, as once our own use of them is removed they'll be completely untested in-tree. Anyway, as noted in <87eea0n04u.fsf@xxxxxxxxxxxxxxxxxxx> I was hoping to take a small step towards finishing up removing the libintl dependency. But after this discussion I think I'm back to mentally classifying that as too tedious of a task to even try, so I wouldn't mind dropping this series of cleanups if we've landed on a consensus of keeping git-sh-setup bug-for-bug compatible going forward, and by extension git-sh-i18n.
