Junio C Hamano wrote: > This seems very specific to use of "less" and hopefully does not do > anything (bad) when a different pager is used by "man". > > - Would it help readers to somehow tell that color.man does not > apply at all to those whose "man" does not "less" in the > documentation? Indeed it would. Done. > - What does it mean to set this variable to "always"? For commands > that we control how the various pieces of output are colored (or > not), e.g. > > $ git -c color.ui=always log -1 -p >git-log-output.txt > > it is obvious what "always" means, but given the implementation > that tweaks how "less" should behave, a similar command (below) > would not colorize its output like the "git log" example above > does, would it? > > $ git -c color.man=always help -m git >git-help-text.txt > > I am just wondering if we are better off not to mention "always" in > the documentation patch above. It seems more like that the > configuration variable is to answer this question and nothing else: > > when 'git help' shows manual pages and internally uses 'less' as > its pager, do we tell it to colorize the output? > > for which sensible answers are 'true' or 'false'. For that matter, > it is not clear what "auto" ought to mean, either. True. The user most likely is not going to run 'git help $x > output'. Initially I was making color.man a boolean, but stopped when I found color.pager. Since Jeff said to use want_color() in the same way all the other color.* configurations, I forgot, and used a colorbool. I've returned back to a bool, and updated the documentation. color.ui=auto is still respected (if stdout is a tty color is disabled), but it doesn't really matter because less seems to be smart and disable color anyway. v3 sent. Cheers. -- Felipe Contreras
