Jeff King wrote: > I am a little nervous that we would be breaking scripts that pipe the > colorized output for later display to the user. Right now doing > something like[1]: > > log=`git log --format=%Cred%h` > test "x$log" != x && echo "foo: $log" > > colorizes, but we would be breaking it. And for new values like > %C(diff.commit), we are not breaking anything (because it is a new > syntax), but a script like the one above may want to convert, and there > is no way to say "respect the color _config_, but don't respect > isatty(1)". Saying "--color" doesn't work, because it overrides the > color config. We can cheat a little with GIT_PAGER_IN_USE, but that will > have funny interactions with pager.color. Very interesting. I think the natural solution (for new colors) would be a --color=config option, which would require parsing options before checking configuration. Does this sound sane? Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html