From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, tom.saeger@oracle.com, gitster@pobox.com,
sunshine@sunshineco.com,
Derrick Stolee <derrickstolee@github.com>,
Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH 3/5] refspec: output a refspec item
Date: Thu, 08 Apr 2021 00:05:15 +0200 [thread overview]
Message-ID: <87czv5kaxw.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <b3e00d3e-c782-9f2a-14e0-f576e50a7e55@gmail.com>
On Wed, Apr 07 2021, Derrick Stolee wrote:
> On 4/7/2021 4:46 AM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Mon, Apr 05 2021, Derrick Stolee via GitGitGadget wrote:
>>> + return buf.buf;
>>
>> There's a downthread discussion about the strbuf usage here so that's
>> covered.
>
> And it's fixed in v2.
>
>> But I'm still confused about the need for this function and the
>> following two patches. If we apply this on top of your series:
>>
>> diff --git a/t/helper/test-refspec.c b/t/helper/test-refspec.c
>> index 08cf441a0a0..9e099e43ebf 100644
>> --- a/t/helper/test-refspec.c
>> +++ b/t/helper/test-refspec.c
>> @@ -31,7 +31,7 @@ int cmd__refspec(int argc, const char **argv)
>> continue;
>> }
>>
>> - printf("%s\n", refspec_item_format(&rsi));
>> + puts(line.buf);
>> refspec_item_clear(&rsi);
>> }
>>
>> The only failing test is:
>>
>> + diff -u expect output
>> --- expect 2021-04-07 08:12:05.577598038 +0000
>> +++ output 2021-04-07 08:12:05.577598038 +0000
>> @@ -11,5 +11,5 @@
>> refs/heads*/for-linus:refs/remotes/mine/*
>> 2e36527f23b7f6ae15e6f21ac3b08bf3fed6ee48:refs/heads/fixed
>> HEAD
>> -HEAD
>> +@
>> :
>
> It should be obvious that taking refspecs as input, parsing them,
> then reformatting them for output should be almost equivalent to
> printing the input line.
>
> The point is to exercise the logic that actually formats the
> refspec for output. The test-tool clearly does this.
>
> The logic for converting a 'struct refspec_item' to a string is
> non-trivial and worth testing. I don't understand why you are
> concerned that the black-box of the test-tool could be done
> more easily to "trick" the test script.
Yes, but why do we need to convert it to a struct refspec_item in the
first place?
Maybe I'm just overly comfortable with string munging but I think the
smaller patch-on-top to use strbuf_splice() is simpler than adding a new
API just for this use-case.
But I'm still wondering if that @ v.s. HEAD case is something this
series actually needs in its end goal (but then has a missing test?), or
if it was just a "let's test the guts of the refspec.c while we're at
it".
>> So the purpose of this new API is that we don't want to make the
>> assumption that strrchr(buf, ':') is a safe way to find the delimiter in
>> the refspec, or is there some case where we grok "HEAD" but not "@"
>> that's buggy, but not tested for in this series?
>
> The purpose is to allow us to modify a 'struct refspec_item' andproduce a refspec string instead of munging a refspec string
> directly.
But aren't we doing that all over the place, e.g. the grep results for
"refspec_appendf". Even for things purely constructed on the C API level
we pass a const char* now.
I'm not saying it wouldn't be nice to have the refspec.c API changed to
have a clear delimitation between its const char* handling, and C-level
uses which could construct and pass a "struct refspec_item" instead.
But is it *needed* here in a way that I've missed, or is this just a
partial testing/refactoring of that API while we're at it?
[Guessing ahead here because of our TZ difference]:
It seems to me that if this is such a partial refactoring it's a strange
way to go about it.
We're left with freeing/munging the "struct refspec" src/dst in-place
and re-constructing a string that has "+" etc., but we already had that
data in parse_refspec() just before we'd call
refspec_item_format(). That function could then just spew out a
pre-formatted string we'd squirreled away in "struct refspec_item".
If the lengthy paragraph you have at the end of 4/5 holds true, then
such an internal representation doesn't need to have the "refs/" prefix
stores as a const char* (in cases where it's not just "*" or whatever),
no?. We'd then be able to more easily init/copy/munge the refspec for
formatting.
next prev parent reply other threads:[~2021-04-07 22:05 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-05 13:04 [PATCH 0/5] Maintenance: adapt custom refspecs Derrick Stolee via GitGitGadget
2021-04-05 13:04 ` [PATCH 1/5] maintenance: simplify prefetch logic Derrick Stolee via GitGitGadget
2021-04-05 17:01 ` Tom Saeger
2021-04-05 13:04 ` [PATCH 2/5] test-lib: use exact match for test_subcommand Derrick Stolee via GitGitGadget
2021-04-05 17:31 ` Eric Sunshine
2021-04-05 17:43 ` Junio C Hamano
2021-04-05 13:04 ` [PATCH 3/5] refspec: output a refspec item Derrick Stolee via GitGitGadget
2021-04-05 16:57 ` Tom Saeger
2021-04-05 17:40 ` Eric Sunshine
2021-04-05 17:44 ` Junio C Hamano
2021-04-06 11:21 ` Derrick Stolee
2021-04-06 15:23 ` Eric Sunshine
2021-04-06 16:51 ` Derrick Stolee
2021-04-07 8:46 ` Ævar Arnfjörð Bjarmason
2021-04-07 20:53 ` Derrick Stolee
2021-04-07 22:05 ` Ævar Arnfjörð Bjarmason [this message]
2021-04-07 22:49 ` Junio C Hamano
2021-04-07 23:01 ` Ævar Arnfjörð Bjarmason
2021-04-08 7:33 ` Junio C Hamano
2021-04-05 13:04 ` [PATCH 4/5] test-tool: test refspec input/output Derrick Stolee via GitGitGadget
2021-04-05 17:52 ` Eric Sunshine
2021-04-06 11:13 ` Derrick Stolee
2021-04-07 8:54 ` Ævar Arnfjörð Bjarmason
2021-04-05 13:04 ` [PATCH 5/5] maintenance: allow custom refspecs during prefetch Derrick Stolee via GitGitGadget
2021-04-05 17:16 ` Tom Saeger
2021-04-06 11:15 ` Derrick Stolee
2021-04-07 8:53 ` Ævar Arnfjörð Bjarmason
2021-04-07 10:26 ` Ævar Arnfjörð Bjarmason
2021-04-09 11:48 ` Derrick Stolee
2021-04-09 19:28 ` Ævar Arnfjörð Bjarmason
2021-04-10 0:56 ` Derrick Stolee
2021-04-10 11:37 ` Ævar Arnfjörð Bjarmason
2021-04-07 13:47 ` Ævar Arnfjörð Bjarmason
2021-04-06 18:47 ` [PATCH v2 0/5] Maintenance: adapt custom refspecs Derrick Stolee via GitGitGadget
2021-04-06 18:47 ` [PATCH v2 1/5] maintenance: simplify prefetch logic Derrick Stolee via GitGitGadget
2021-04-07 23:23 ` Emily Shaffer
2021-04-09 19:00 ` Derrick Stolee
2021-04-06 18:47 ` [PATCH v2 2/5] test-lib: use exact match for test_subcommand Derrick Stolee via GitGitGadget
2021-04-06 18:47 ` [PATCH v2 3/5] refspec: output a refspec item Derrick Stolee via GitGitGadget
2021-04-06 18:47 ` [PATCH v2 4/5] test-tool: test refspec input/output Derrick Stolee via GitGitGadget
2021-04-07 23:08 ` Josh Steadmon
2021-04-07 23:26 ` Emily Shaffer
2021-04-06 18:47 ` [PATCH v2 5/5] maintenance: allow custom refspecs during prefetch Derrick Stolee via GitGitGadget
2021-04-06 19:36 ` Tom Saeger
2021-04-06 19:45 ` Derrick Stolee
2021-04-07 23:09 ` Josh Steadmon
2021-04-07 23:37 ` Emily Shaffer
2021-04-08 0:23 ` Jonathan Tan
2021-04-10 2:03 ` [PATCH v3 0/3] Maintenance: adapt custom refspecs Derrick Stolee via GitGitGadget
2021-04-10 2:03 ` [PATCH v3 1/3] maintenance: simplify prefetch logic Derrick Stolee via GitGitGadget
2021-04-12 20:13 ` Tom Saeger
2021-04-12 20:27 ` Derrick Stolee
2021-04-10 2:03 ` [PATCH v3 2/3] fetch: add --prefetch option Derrick Stolee via GitGitGadget
2021-04-11 21:09 ` Ramsay Jones
2021-04-12 20:23 ` Derrick Stolee
2021-04-10 2:03 ` [PATCH v3 3/3] maintenance: use 'git fetch --prefetch' Derrick Stolee via GitGitGadget
2021-04-11 1:35 ` [PATCH v3 0/3] Maintenance: adapt custom refspecs Junio C Hamano
2021-04-12 16:48 ` Tom Saeger
2021-04-12 17:24 ` Tom Saeger
2021-04-12 17:41 ` Tom Saeger
2021-04-12 20:25 ` Derrick Stolee
2021-04-16 12:49 ` [PATCH v4 0/4] " Derrick Stolee via GitGitGadget
2021-04-16 12:49 ` [PATCH v4 1/4] maintenance: simplify prefetch logic Derrick Stolee via GitGitGadget
2021-04-16 18:02 ` Tom Saeger
2021-04-16 12:49 ` [PATCH v4 2/4] fetch: add --prefetch option Derrick Stolee via GitGitGadget
2021-04-16 17:52 ` Tom Saeger
2021-04-16 18:26 ` Tom Saeger
2021-04-16 12:49 ` [PATCH v4 3/4] maintenance: use 'git fetch --prefetch' Derrick Stolee via GitGitGadget
2021-04-16 12:49 ` [PATCH v4 4/4] maintenance: respect remote.*.skipFetchAll Derrick Stolee via GitGitGadget
2021-04-16 13:54 ` Ævar Arnfjörð Bjarmason
2021-04-16 14:33 ` Tom Saeger
2021-04-16 18:31 ` Tom Saeger
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czv5kaxw.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=stolee@gmail.com \
--cc=sunshine@sunshineco.com \
--cc=tom.saeger@oracle.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.
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 NNTP newsgroup(s).