All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 9/9] sub-process: do not use strbuf_split*()
Date: Thu, 31 Jul 2025 07:30:01 -0700	[thread overview]
Message-ID: <xmqqikj8touu.fsf@gitster.g> (raw)
In-Reply-To: <CAP8UFD2qAOhRN=b9PB_eXQS1PntZKX95ZK=V4G=10n3iU2xtbw@mail.gmail.com> (Christian Couder's message of "Thu, 31 Jul 2025 10:50:50 +0200")

Christian Couder <christian.couder@gmail.com> writes:

> On Thu, Jul 31, 2025 at 9:44 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> The code to read status from subprocess reads one packet line and
>> tries to find "status=<foo>".  It is way overkill to split the line
>> into an array of two strbufs to extract <foo>.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>  sub-process.c | 16 +++++++---------
>>  1 file changed, 7 insertions(+), 9 deletions(-)
>>
>> diff --git a/sub-process.c b/sub-process.c
>> index 1daf5a9752..de3235c15a 100644
>> --- a/sub-process.c
>> +++ b/sub-process.c
>> @@ -5,6 +5,7 @@
>>  #include "sub-process.h"
>>  #include "sigchain.h"
>>  #include "pkt-line.h"
>> +#include "string-list.h"
>
> Is this needed? It looks like skip_prefix() (not any string_list
> function) is used instead of strbuf_split_str().

Yes, as you suspected, I initially rewrote strbuf_split*() with
string_list_split*(), but then realized there is no need to split
the string into tokens in the first place.

Will remove the unused include.
Thanks for carefully reading.

  reply	other threads:[~2025-07-31 14:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31  7:41 [PATCH 0/9] do not overuse strbuf_split*() Junio C Hamano
2025-07-31  7:41 ` [PATCH 1/9] wt-status: avoid strbuf_split*() Junio C Hamano
2025-07-31  7:41 ` [PATCH 2/9] clean: do not pass strbuf by value Junio C Hamano
2025-07-31  7:41 ` [PATCH 3/9] clean: do not use strbuf_split*() [part 1] Junio C Hamano
2025-07-31  7:41 ` [PATCH 4/9] clean: do not use strbuf_split*() [part 2] Junio C Hamano
2025-07-31  7:41 ` [PATCH 5/9] merge-tree: do not use strbuf_split*() Junio C Hamano
2025-07-31  7:41 ` [PATCH 6/9] notes: " Junio C Hamano
2025-07-31 20:14   ` Eric Sunshine
2025-07-31  7:41 ` [PATCH 7/9] config: do not use strbuf_split() Junio C Hamano
2025-07-31 20:15   ` Eric Sunshine
2025-07-31  7:41 ` [PATCH 8/9] environment: do not use strbuf_split*() Junio C Hamano
2025-07-31  7:41 ` [PATCH 9/9] sub-process: " Junio C Hamano
2025-07-31  8:50   ` Christian Couder
2025-07-31 14:30     ` Junio C Hamano [this message]
2025-07-31 22:54 ` [PATCH v2 00/11] do not overuse strbuf_split*() Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 01/11] wt-status: avoid strbuf_split*() Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 02/11] clean: do not pass strbuf by value Junio C Hamano
2025-08-02  8:38     ` Jeff King
2025-08-02 16:44       ` Junio C Hamano
2025-08-02 18:40         ` Jeff King
2025-07-31 22:54   ` [PATCH v2 03/11] clean: do not use strbuf_split*() [part 1] Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 04/11] clean: do not use strbuf_split*() [part 2] Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 05/11] merge-tree: do not use strbuf_split*() Junio C Hamano
2025-08-02  8:55     ` Jeff King
2025-07-31 22:54   ` [PATCH v2 06/11] notes: " Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 07/11] config: do not use strbuf_split() Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 08/11] environment: do not use strbuf_split*() Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 09/11] sub-process: " Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 10/11] trace2: trim_trailing_newline followed by trim is a no-op Junio C Hamano
2025-07-31 22:54   ` [PATCH v2 11/11] trace2: do not use strbuf_split*() Junio C Hamano
2025-08-02  9:08   ` [PATCH v2 00/11] do not overuse strbuf_split*() Jeff King
2025-08-02 17:09     ` Junio C Hamano
2025-08-02 18:47       ` Jeff King

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=xmqqikj8touu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.