Jeff King venit, vidit, dixit 07.12.2009 06:17: > On Sat, Dec 05, 2009 at 04:04:38PM +0100, Michael J Gruber wrote: > >> Make the short version of status obey the color.status boolean. We color >> the status letters only, because they carry the state information and are >> potentially colored differently, such as for a file with staged changes >> as well as changes in the worktree against the index. > > This seems to also turn on color for --porcelain in some cases, because > git_status_config unconditionally sets s->use_color if you are using > color.status instead of color.ui. I think we are probably best just > explicitly disabling options for the "porcelain" format rather than > trying to come up with some trickery to make sure they never get set. > Like: Thanks. I let myself get fooled by the apparent option handling within the switch statement (which is OK for relativePaths) (and some subconscious link between null_termination and porcelain, which goes one way only). I guess this shows (again) that one needs tests for everything... If I get around to I'll amend t$(relevantoneicantrecallrightnow) with tests for long and short status with color and porcelain with the various options. Michael -- 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