On Mon, Aug 01, 2016 at 08:01:13PM +0200, Duy Nguyen wrote: > > If you are interested, I suggest you read the thread linked earlier: > > > > https://public-inbox.org/git/52D87A79.6060600%40rawbw.com/T/#u > > > > which discusses this and other issues. But basically, I think you cannot > > really solve this without getting intimate with each pager (which people > > seemed not to want to do). > > Cooking pager specifics in git does sound bad. But it does not have to > be that way. What if we delegate the decision whether to color or not > to a script (e.g. by setting color.ui= "script <path to the script>")? > The script has all the info (env variables, uname, user preference...) > and can make a better decision than 'is stdout a tty?'. It's not about > out of the box experience, more towards customization (without > fragmenting .gitconfig files too much).
It sounds like we are solving two separate problems. I was mostly concerned with the out-of-the-box experience. E.g., you build git and run "git log" and it prints out gibberish, either because of your $PAGER or your $LESS settings (which you might have set years ago). For more advanced usage like yours, I'd shove any personal logic into a wrapper around your pager script. I think the particular decision you want, though, is related to color.pager, which is outside that scope. I'm not sure exactly what your setup looks like, but I wonder if it would be served by better config support (i.e., why do you need a script to dynamically look at your pager and see if color.pager should be turned on; can't you configure both at the same time?). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
