From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Stefan Beller <sbeller@google.com>,
"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 03/15] t: use test_decode_color rather than literal ANSI codes
Date: Thu, 13 Jul 2017 12:27:41 -0700 [thread overview]
Message-ID: <xmqqeftkw30y.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170713184541.ferc3eif7j4mazpg@sigill.intra.peff.net> (Jeff King's message of "Thu, 13 Jul 2017 14:45:41 -0400")
Jeff King <peff@peff.net> writes:
>> > @@ -59,7 +54,8 @@ EOF
>> > # to this test since it does not contain any decoration, hence --first-parent
>> > test_expect_success 'Commit Decorations Colored Correctly' '
>> > git log --first-parent --abbrev=10 --all --decorate --oneline --color=always |
>> > - sed "s/[0-9a-f]\{10,10\}/COMMIT_ID/" >out &&
>> > + sed "s/[0-9a-f]\{10,10\}/COMMIT_ID/" |
>> > + test_decode_color >out &&
>>
>> Just some thoughts:
>>
>> This extension of the pipe-chain is not making it worse as gits exit code
>> is already hidden.
>
> Yes, I noticed the existing pipe-chain. We can fix it while we're here,
> though I think it's not a big deal in practice.
>
>> The sed "s/[0-9a-f]\{10,10\}/COMMIT_ID/" is sort of funny, because
>> I would have expected it to break in the future with e.g. the sha1 to longer
>> hash conversion. But as we specify --abbrev=10, this seems future proof.
>> In an ideal world this would be encapsulated in a function (c.f. t/diff-lib.sh).
Actually, --abbrev=10 does not guarantee that the hex part is always
10 bytes long, so it is not future-proofing, but I expect it would
work out fine in practice.
> I agree it's a bit gross. Possibly:
>
> git log --format='%C(auto)%d %s'
>
> would be easier for the test to parse (I'm pretty sure that didn't exist
> back when this test was written).
Yeah, that may make the test easier to read, too.
Thanks.
next prev parent reply other threads:[~2017-07-13 19:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-13 14:55 [PATCH 0/15] making user-format colors conditional on config/tty Jeff King
2017-07-13 14:56 ` [PATCH 01/15] check return value of verify_ref_format() Jeff King
2017-07-13 14:56 ` [PATCH 02/15] docs/for-each-ref: update pointer to color syntax Jeff King
2017-07-13 20:15 ` Junio C Hamano
2017-07-13 14:58 ` [PATCH 03/15] t: use test_decode_color rather than literal ANSI codes Jeff King
2017-07-13 18:40 ` Stefan Beller
2017-07-13 18:45 ` Jeff King
2017-07-13 19:27 ` Junio C Hamano [this message]
2017-07-14 11:50 ` Jeff King
2017-07-13 20:18 ` Junio C Hamano
2017-07-13 14:58 ` [PATCH 04/15] ref-filter: simplify automatic color reset Jeff King
2017-07-13 15:01 ` [PATCH 05/15] ref-filter: abstract ref format into its own struct Jeff King
2017-07-13 18:51 ` Stefan Beller
2017-07-13 20:34 ` Junio C Hamano
2017-07-13 21:32 ` Junio C Hamano
2017-07-13 22:01 ` Stefan Beller
2017-07-13 22:45 ` Junio C Hamano
2017-07-13 15:02 ` [PATCH 06/15] ref-filter: move need_color_reset_at_eol into ref_format Jeff King
2017-07-13 20:36 ` Junio C Hamano
2017-07-13 15:02 ` [PATCH 07/15] ref-filter: provide a function for parsing sort options Jeff King
2017-07-13 15:02 ` [PATCH 08/15] ref-filter: make parse_ref_filter_atom a private function Jeff King
2017-07-13 15:02 ` [PATCH 09/15] ref-filter: factor out the parsing of sorting atoms Jeff King
2017-07-13 15:06 ` [PATCH 10/15] ref-filter: pass ref_format struct to atom parsers Jeff King
2017-07-13 15:07 ` [PATCH 11/15] color: check color.ui in git_default_config() Jeff King
2017-07-13 15:07 ` [PATCH 12/15] for-each-ref: load config earlier Jeff King
2017-07-13 15:07 ` [PATCH 13/15] rev-list: pass diffopt->use_colors through to pretty-print Jeff King
2017-07-13 15:08 ` [PATCH 14/15] pretty: respect color settings for %C placeholders Jeff King
2017-07-13 15:09 ` [PATCH 15/15] ref-filter: consult want_color() before emitting colors Jeff King
2017-07-13 19:14 ` [PATCH 0/15] making user-format colors conditional on config/tty Stefan Beller
2017-07-13 20:46 ` 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=xmqqeftkw30y.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/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).