git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jacob Keller <jacob.keller@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Git mailing list" <git@vger.kernel.org>
Subject: Re: [PATCH] color_parse_mem: allow empty color spec
Date: Tue, 31 Jan 2017 17:19:02 -0800	[thread overview]
Message-ID: <CA+P7+xqT-3_quCwtTya++Zew6y8pSGL2WTTvpGMwKM257w4Vng@mail.gmail.com> (raw)
In-Reply-To: <20170201002129.xb62hmxwrzwgp6vg@sigill.intra.peff.net>

On Tue, Jan 31, 2017 at 4:21 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Jan 31, 2017 at 02:45:40PM -0800, Junio C Hamano wrote:
>
>> * nd/log-graph-configurable-colors (2017-01-23) 3 commits
>>   (merged to 'next' on 2017-01-23 at c369982ad8)
>>  + log --graph: customize the graph lines with config log.graphColors
>>  + color.c: trim leading spaces in color_parse_mem()
>>  + color.c: fix color_parse_mem() with value_len == 0
>>
>>  Some people feel the default set of colors used by "git log --graph"
>>  rather limiting.  A mechanism to customize the set of colors has
>>  been introduced.
>>
>>  Reported to break "add -p".
>>  cf. <20170128040709.tqx4u45ktgpkbfm4@sigill.intra.peff.net>
>
> I hadn't heard anything back, so I wrapped up my fix with a commit
> message and tests (it needs to go on top anyway, since the breakage is
> in 'next').
>

I was just about to report this breakage... It definitely breaks usage
of git-add-interactive..

> -- >8 --
> Subject: [PATCH] color_parse_mem: allow empty color spec
>
> 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 <peff@peff.net>
> ---

The patch looks good to me. Very nice to have a detailed explanation
of why we didn't catch it before, and how to ensure we don't have this
happen again.

Thanks,
Jake

>  color.c                    |  6 ++++--
>  t/t3701-add-interactive.sh | 14 ++++++++++++++
>  t/t4026-color.sh           |  7 ++++++-
>  t/t4202-log.sh             |  2 +-
>  4 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/color.c b/color.c
> index 7bb4a96f8..2925a819b 100644
> --- a/color.c
> +++ b/color.c
> @@ -212,8 +212,10 @@ int color_parse_mem(const char *value, int value_len, char *dst)
>                 len--;
>         }
>
> -       if (!len)
> -               return -1;
> +       if (!len) {
> +               dst[0] = '\0';
> +               return 0;
> +       }
>
>         if (!strncasecmp(ptr, "reset", len)) {
>                 xsnprintf(dst, end - dst, GIT_COLOR_RESET);
> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> index deae948c7..5ffe78e92 100755
> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -380,4 +380,18 @@ test_expect_success 'patch mode ignores unmerged entries' '
>         test_cmp expected diff
>  '
>
> +test_expect_success 'diffs can be colorized' '
> +       git reset --hard &&
> +
> +       # force color even though the test script has no terminal
> +       test_config color.ui always &&
> +
> +       echo content >test &&
> +       printf y | git add -p >output 2>&1 &&
> +
> +       # We do not want to depend on the exact coloring scheme
> +       # git uses for diffs, so just check that we saw some kind of color.
> +       grep "$(printf "\\033")" output
> +'
> +
>  test_done
> diff --git a/t/t4026-color.sh b/t/t4026-color.sh
> index ec78c5e3a..671e951ee 100755
> --- a/t/t4026-color.sh
> +++ b/t/t4026-color.sh
> @@ -6,10 +6,11 @@
>  test_description='Test diff/status color escape codes'
>  . ./test-lib.sh
>
> +ESC=$(printf '\033')
>  color()
>  {
>         actual=$(git config --get-color no.such.slot "$1") &&
> -       test "$actual" = " $2"
> +       test "$actual" = "${2:+$ESC}$2"
>  }
>
>  invalid_color()
> @@ -21,6 +22,10 @@ test_expect_success 'reset' '
>         color "reset" "[m"
>  '
>
> +test_expect_success 'empty color is empty' '
> +       color "" ""
> +'
> +
>  test_expect_success 'attribute before color name' '
>         color "bold red" "[1;31m"
>  '
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 0aeabed96..1edbb1e7f 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -329,7 +329,7 @@ cat > expect.colors <<\EOF
>  EOF
>
>  test_expect_success 'log --graph with merge with log.graphColors' '
> -       test_config log.graphColors ",, blue,invalid-color, cyan, red  , " &&
> +       test_config log.graphColors " blue,invalid-color, cyan, red  , " &&
>         git log --color=always --graph --date-order --pretty=tformat:%s |
>                 test_decode_color | sed "s/ *\$//" >actual &&
>         test_cmp expect.colors actual
> --
> 2.11.0.948.gca97da533
>

  reply	other threads:[~2017-02-01  1:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 22:45 What's cooking in git.git (Jan 2017, #06; Tue, 31) Junio C Hamano
2017-02-01  0:21 ` [PATCH] color_parse_mem: allow empty color spec Jeff King
2017-02-01  1:19   ` Jacob Keller [this message]
2017-02-02  9:16   ` Duy Nguyen
2017-02-02 12:42     ` [PATCH] document behavior of empty color name Jeff King
2017-02-03  9:24       ` Duy Nguyen
2017-02-03 12:29         ` Jeff King
2017-02-03 18:12           ` Junio C Hamano
2017-02-04  0:49             ` Jeff King
2017-02-01 11:08 ` What's cooking in git.git (Jan 2017, #06; Tue, 31) Patrick Steinhardt
2017-02-01 18:40   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+P7+xqT-3_quCwtTya++Zew6y8pSGL2WTTvpGMwKM257w4Vng@mail.gmail.com \
    --to=jacob.keller@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).