From: Derrick Stolee <stolee@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Jon Simons <jon@jonsimons.org>, git@vger.kernel.org, me@ttaylorr.com
Subject: Re: [PATCH 2/2] list-objects-filter: handle unresolved sparse filter OID
Date: Thu, 29 Aug 2019 10:28:42 -0400 [thread overview]
Message-ID: <2ed6a754-07ef-9131-2655-6d3fd3308623@gmail.com> (raw)
In-Reply-To: <20190829134439.GA1797@sigill.intra.peff.net>
On 8/29/2019 9:44 AM, Jeff King wrote:
> On Thu, Aug 29, 2019 at 09:12:38AM -0400, Derrick Stolee wrote:
>
>>> +test_expect_success 'partial clone with unresolvable sparse filter fails cleanly' '
>>> + test_must_fail git clone --no-local --no-checkout --filter=sparse:oid=master:sparse-filter "file://$(pwd)/sparse-src" sc1 2>err &&
>>> + test_i18ngrep "unable to read sparse filter specification from sparse:oid=master:sparse-filter" err &&
>>> + test_must_fail git clone --no-local --no-checkout --filter=sparse:oid=master "file://$(pwd)/sparse-src" sc2 2>err &&
>>> + test_i18ngrep "unable to parse sparse filter data in $(git -C sparse-src rev-parse master)" err
>>
>> Just as a sanity check: when we use test_i18ngrep, how does it know how to
>> separate the part that is translated and which part is not?
>>
>> translated: "unable to read sparse filter specification from"
>> not translated: "sparse:oid=master"
>
> It doesn't know. By default we run the suite in LOCALE=C and it checks
> the whole string. Under a GETTEXT_POISON build, it checks nothing at
> all.
>
> The poison stuff is really about helping people not accidentally mark a
> plumbing string (that we expect to get parsed by a machine) as
> translatable. So the idea is you'd build with GETTEXT_POISON and then
> run the test suite to see if anything breaks. But that means we also
> have to annotate the test suite with "yes, I know this will be gibberish
> in a poison build, but that's OK because it's meant for humans". And
> that's what test_i18ngrep is.
>
> test_i18ngrep could be more clever about matching the gibberish, but
> there's not much point. The LOCALE=C run already covered the correctness
> of checking the message.
Thanks for clearing this up for me!
-Stolee
prev parent reply other threads:[~2019-08-29 14:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 20:18 [PATCH 0/2] partial-clone: fix two issues with sparse filter handling Jon Simons
2019-08-28 20:18 ` [PATCH 1/2] list-objects-filter: only parse sparse OID when 'have_git_dir' Jon Simons
2019-08-28 21:10 ` Eric Sunshine
2019-08-28 23:35 ` Jeff King
2019-08-28 20:18 ` [PATCH 2/2] list-objects-filter: handle unresolved sparse filter OID Jon Simons
2019-08-29 13:12 ` Derrick Stolee
2019-08-29 13:44 ` Jeff King
2019-08-29 14:28 ` Derrick Stolee [this message]
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=2ed6a754-07ef-9131-2655-6d3fd3308623@gmail.com \
--to=stolee@gmail.com \
--cc=git@vger.kernel.org \
--cc=jon@jonsimons.org \
--cc=me@ttaylorr.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).