path: root/t/
AgeCommit message (Collapse)Author
2020-02-11color.c: alias RGB colors 8-15 to aixterm colorsEyal Soha
This results in shorter output, and is _probably_ more portable. There is at least one environment (GitHub Actions) which supports 16-color mode but not 256-color mode. It's possible there are environments which go the other way, but it seems unlikely. Signed-off-by: Eyal Soha <> Signed-off-by: Junio C Hamano <>
2020-02-11color.c: support bright aixterm colorsEyal Soha
These colors are the bright variants of the 3-bit colors. Instead of 30-37 range for the foreground and 40-47 range for the background, they live in 90-97 and 100-107 range, respectively. Signed-off-by: Eyal Soha <> Signed-off-by: Junio C Hamano <>
2017-02-01color_parse_mem: allow empty color specJeff King
Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-06-23color: support strike-through attributeJeff King
This is the only remaining attribute that is commonly supported (at least by xterm) that we don't support. Let's add it for completeness. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-06-23color: support "italic" attributeJeff King
We already support bold, underline, and similar attributes. Let's add italic to the mix. According to the Wikipedia page on ANSI colors, this attribute is "not widely supported", but it does seem to work on my xterm. We don't have to bump the maximum color size because we were already over-allocating it (but we do adjust the comment appropriately). Requested-by: Simon Courtois <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-06-23color: allow "no-" for negating attributesJeff King
Using "no-bold" rather than "nobold" is easier to read and more natural to type (to me, anyway, even though I was the person who introduced "nobold" in the first place). It's easy to allow both. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-03-20t: wrap complicated expect_code users in a blockJeff King
If we are expecting a command to produce a particular exit code, we can use test_expect_code. However, some cases are more complicated, and want to accept one of a range of exit codes. For these, we end up with something like: cmd; case "$?" in ... That unfortunately breaks the &&-chain and fools --chain-lint. Since these special cases are so few, we can wrap them in a block, like this: { cmd; ret=$?; } && case "$ret" in ... This accomplishes the same thing, and retains the &&-chain (the exit status fed to the && is that of the assignment, which should always be true). It's technically longer, but it is probably a good thing for unusual code like this to stand out. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-01-20parse_color: fix return value for numeric color values 0-8Jeff King
When commit 695d95d refactored the color parsing, it missed a "return 0" when parsing literal numbers 0-8 (which represent basic ANSI colors), leading us to report these colors as an error. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-11-20parse_color: recognize "no$foo" to clear the $foo attributeJeff King
You can turn on ANSI text attributes like "reverse" by putting "reverse" in your color spec. However, you cannot ask to turn reverse off. For common cases, this does not matter. You would turn on "reverse" at the start of a colored section, and then clear all attributes with a "reset". However, you may wish to turn on some attributes, then selectively disable others. For example: git log --format="%C(bold ul yellow)%h%C(noul) %s" underlines just the hash, but without the need to re-specify the rest of the attributes. This can also help third-party programs, like contrib/diff-highlight, that want to turn some attribute on/off without disrupting existing coloring. Note that some attribute specifications are probably nonsensical (e.g., "bold nobold"). We do not bother to flag such constructs, and instead let the terminal sort it out. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-11-20parse_color: support 24-bit RGB valuesJeff King
Some terminals (like XTerm) allow full 24-bit RGB color specifications using an extension to the regular ANSI color scheme. Let's allow users to specify hex RGB colors, enabling the all-important feature of hot pink ref decorations: git log --format="%h%C(#ff69b4)%d%C(reset) %s" Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-11-20t4026: test "normal" colorJeff King
If the user specifiers "normal" for a foreground color, this should be a noop (while this may sound useless, it is the only way to specify an unchanged foreground color followed by a specific background color). We also check that color "-1" does the same thing. This is not documented, but has worked forever, so let's make sure we keep supporting it. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2010-10-06t4026 (color): remove unneeded and unchained commandElijah Newren
Ever since 8b12413 (color: allow multiple attributes 2010-02-27), has been unused in t4026, so also remove the final unsetting of that value to make the third to last test pass with appropriate '&&' chaining. Acked-by: Ævar Arnfjörð Bjarmason <> Acked-by: Jeff King <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2010-03-20Merge branch 'jc/color-attrs'Junio C Hamano
* jc/color-attrs: color: allow multiple attributes
2010-03-07color: allow multiple attributesJunio C Hamano
In configuration files (and "git config --color" command line), we supported one and only one attribute after foreground and background color. Accept combinations of attributes, e.g. [diff.color] old = red reverse bold Signed-off-by: Junio C Hamano <>
2009-12-16ignore unknown color configurationJeff King
When parsing the config file, if there is a value that is syntactically correct but unused, we generally ignore it. This lets non-core porcelains store arbitrary information in the config file, and it means that configuration files can be shared between new and old versions of git (the old versions might simply ignore certain configuration). The one exception to this is color configuration; if we encounter a color.{diff,branch,status}.$slot variable, we die if it is not one of the recognized slots (presumably as a safety valve for user misconfiguration). This behavior has existed since 801235c (diff --color: use $GIT_DIR/config, 2006-06-24), but hasn't yet caused a problem. No porcelain has wanted to store extra colors, and we once a color area (like color.diff) has been introduced, we've never changed the set of color slots. However, that changed recently with the addition of color.diff.func. Now a user with color.diff.func in their config can no longer freely switch between v1.6.6 and older versions; the old versions will complain about the existence of the variable. This patch loosens the check to match the rest of git-config; unknown color slots are simply ignored. This doesn't fix this particular problem, as the older version (without this patch) is the problem, but it at least prevents it from happening again in the future. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2008-02-06Fix parsing numeric color valuesTimo Hirvonen
Numeric color only worked if it was at end of line. Noticed by Chris Larson <>. Signed-off-by: Timo Hirvonen <> Signed-off-by: Junio C Hamano <>