Hi Junio, [and welcome back, at least I hope you only read this after a good and relaxing vacation] On Fri, 16 Feb 2018, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > > > Now, what would be possible solutions for this? > > > > - introduce `int fd` in `want_color()` (and callees) so that we can make > > a distinction whether we want to detect whether stdout or stderr is connected > > to a tty > > > > - introduce a separate `want_color_stderr()` (we still would need to decide > > whether we want a config setting for this) > > Between the above two, there probably aren't so big a difference, but > in order to avoid disrupting existing callers of want_color() while > possibly sharing as much code between the old and new callers, > perhaps: > > extern int want_color_fd(int fd, int colorbool); > #define want_color(colorbool) want_color_fd(1, (colorbool)) > #define want_color_stderr(colorbool) want_color_fd(2, (colorbool)) I made it so. Note that I also had to change the check_auto_color() function, and while want_color_fd() can have a "private" record of previous results, check_auto_color() needs to use the global color_stdout_is_tty (so that builtin/config.c can edit it, for use in `git config --colorbool <name> [stdout-is-tty]`). > We should honor configuration at two levels, just like the colors on > stdout, i.e. color in which individual items are painted (e.g. > color.diff.filename, color.advice.hint) and whether we use colors in > UI at all (e.g. color.ui). This is how v2 does it. Thanks for your suggestions, Dscho
