On Sat, May 05, 2007 at 07:58:45PM +0200, Johannes Schindelin wrote: > AFAIR there have been attempts to enable this by default, when git-status > is run interactively (i.e. its output is not piped). However, this proved > to be remarkably complex, given that the output of runstatus _is_ piped. I have been running with "status.color" set to "auto" for months, and it works fine. git-status sends the output of runstatus to stdout; only git-commit saves it in a file. However, that is irrelevant here since git-commit explicitly turns off color anyway. The reason for this is that the result ends up in the user's editor and in the commit object. In the editor, it is more elegant to do syntax highlighting at that level (otherwise you have to edit around the escape codes). For the commit object, we would have to put in code to strip the colorization. My biggest complaint is that git-commit shows the runstatus output to the user if there is nothing to commit, but it isn't colorized (because we created it with the intent of running the editor on it). This could be fixed at the expense of slightly more CPU by simply re-running runstatus instead of using the saved copy. > IMHO the proper solution would be to go the full nine yards, and teach > runstatus about the remaining parts of git-status. Then, automatic color > works automatically. When I rewrote runstatus in C, it was always my intent that it just be a first step in turning git-status into a C builtin (with the ultimate goal of improving the output by parallel walking the HEAD, index, and working tree). Unfortunately, I don't seem to have gotten around to it... -Peff - 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