threads / patch / 64329

v2, 2 partsgpg-interface.c: use string_list_split() instead of strbuf_split_max()

Subject: [Outreachy PATCH v2 0/2] gpg-interface.c: use string_list_split() instead of strbuf_split_max()

## tl;dr

10 messages between Oct 16, 2025 and Oct 17, 2025. Diffs are folded; open one to read it.

replies: 9people: 3as markdown or json

Olamide Caleb Bello· Oct 16, 2025, 01:03 UTC · lore

Commit 2efe707054 (wt-status: avoid strbuf_split*(), 2025-07-31) noticed that the array of strbufs that calls to strbuf_split*() provides are merely used to store the strings gotten from the split and no edit are done on these resulting strings making the strbuf_split*() unideal for this usecase, with the string_list_split*() being a more suitable option.

The patch series by Junio Hamano can be seen in the link below.
https://public-inbox.org/git/20250731225433.4028872-1-gitster@pobox.com/

This series continues on this path by replacing instances of strbuf_split_max() with string_list_split() where the string from the split is merely returned as char * and no edits are done on them.

Changes since v1
================
 - Added commit reference and link to patch series for previous work
 done on the subject
Olamide Caleb Bello (2):
  gpg-interface: replace strbuf_split_max() with string_list_split()
  gpg-interface: use string_list_split() instead of strbuf_split_max()
 gpg-interface.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)
-- 
2.51.0.463.g79cf913ea9
Olamide Caleb Bello· Oct 16, 2025, 01:03 UTC · re: Olamide Caleb Bello · lore

[Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split()

In get_ssh_finger_print(), the output of the `ssh-keygen` command is put into `fingerprint_stdout

The string in fingerprint_stdout is then split into 3 strbufs using strbuf_split_max(), however they are not modified after the split thereby not making use of the strbuf API as the fingerprint token is merely returned as a char * and not a strbuf, hence they do not need to be strbufs.

Use string_list_split() instead for simplicity.

Note that strbuf_split_max() uses 3 to specify the number of tokens to extract from the string, while string_list_split() uses 2 because it specifies the number of times the split will be done on the string, so 2 gives 3 tokens as it is in the original instance.

Signed-off-by: Olamide Caleb Bello <belkid98@gmail.com>
---
 Changes in v2
   - Reword the commit message for clarity
   - Add () to the function names
   - Change the test to ensure the number of tokens appended to the
    list by string_list_split() equals 3
 gpg-interface.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Show changes to gpg-interface.c +5 −5
diff --git a/gpg-interface.c b/gpg-interface.c
index 2f4f0e32cb..989dca7d14 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -14,6 +14,7 @@
 #include "sigchain.h"
 #include "tempfile.h"
 #include "alias.h"
+#include "string-list.h"
 
 static int git_gpg_config(const char *, const char *,
 			  const struct config_context *, void *);
@@ -821,7 +822,7 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
 	struct child_process ssh_keygen = CHILD_PROCESS_INIT;
 	int ret = -1;
 	struct strbuf fingerprint_stdout = STRBUF_INIT;
-	struct strbuf **fingerprint;
+	struct string_list split = STRING_LIST_INIT_DUP;
 	char *fingerprint_ret;
 	const char *literal_key = NULL;
 
@@ -845,13 +846,12 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
 		die_errno(_("failed to get the ssh fingerprint for key '%s'"),
 			  signing_key);
 
-	fingerprint = strbuf_split_max(&fingerprint_stdout, ' ', 3);
-	if (!fingerprint[1])
+	if (string_list_split(&split, fingerprint_stdout.buf, " ", 2) != 3)
 		die_errno(_("failed to get the ssh fingerprint for key '%s'"),
 			  signing_key);
 
-	fingerprint_ret = strbuf_detach(fingerprint[1], NULL);
-	strbuf_list_free(fingerprint);
+	fingerprint_ret = xstrdup(split.items[1].string);
+	string_list_clear(&split, 0);
 	strbuf_release(&fingerprint_stdout);
 	return fingerprint_ret;
 }
-- 
2.51.0.463.g79cf913ea9
Junio C Hamano· Oct 16, 2025, 17:27 UTC · re: Olamide Caleb Bello · lore

Re: [Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split()

Olamide Caleb Bello <belkid98@gmail.com> writes:
Show 16 quoted lines
> @@ -821,7 +822,7 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
>  	struct child_process ssh_keygen = CHILD_PROCESS_INIT;
>  	int ret = -1;
>  	struct strbuf fingerprint_stdout = STRBUF_INIT;
> -	struct strbuf **fingerprint;
> +	struct string_list split = STRING_LIST_INIT_DUP;
>  	char *fingerprint_ret;
>  	const char *literal_key = NULL;
>  
> @@ -845,13 +846,12 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
>  		die_errno(_("failed to get the ssh fingerprint for key '%s'"),
>  			  signing_key);
>  
> -	fingerprint = strbuf_split_max(&fingerprint_stdout, ' ', 3);
> -	if (!fingerprint[1])
> +	if (string_list_split(&split, fingerprint_stdout.buf, " ", 2) != 3)

The original splits the thing into upto 3 pieces, but only complains if the second piece is NULL (i.e. we said "up to 3", but there was not even one place to split, and the request to split_max gave the one thing as one piece). IOW, the original code will happily accept if the finterprint_stdout is split only into two, not three.

The updated code asks to split at at most two places (yes, it is a confusing API, but if you split at two places, you will end up with three pieces), and insists that the split results in three pieces.

So the rewrite tightens the error condition.

Was the original code too loose in detecting an error, and does this patch tightens the condition "while at it"? Or was the original code correct to expect that there are legitimate cases where the payload in finterprint_stdout only contains two pieces, and it was the right thing to do to accept when fingerprint[1] is not NULL but fingerprint[2] is NULL?

This is a genuine question. I haven't studied the code path to reach this point in the code flow, I don't know what the data in fingerprint_stdout is supposed to look like, so I do not know the answer to the question (in other words, it cannot be an oblique way to point out that the updated code is wrong or anything like that).

Show 8 quoted lines
>  		die_errno(_("failed to get the ssh fingerprint for key '%s'"),
>  			  signing_key);
>  
> -	fingerprint_ret = strbuf_detach(fingerprint[1], NULL);
> -	strbuf_list_free(fingerprint);
> +	fingerprint_ret = xstrdup(split.items[1].string);
> +	string_list_clear(&split, 0);
>  	strbuf_release(&fingerprint_stdout);

Since this code releases fingerprint_stdout before leaving, and returns a fresh copy of a split piece, it may make more sense to use string_list_split_in_place(), which does not have to allocate extra strings while it does its work, unlike string_list_split().

>  	return fingerprint_ret;
>  }
Christian Couder· Oct 17, 2025, 09:15 UTC · re: Junio C Hamano · lore

Re: [Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split()

On Thu, Oct 16, 2025 at 7:27 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 44 quoted lines
>
> Olamide Caleb Bello <belkid98@gmail.com> writes:
>
> > @@ -821,7 +822,7 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> >       struct child_process ssh_keygen = CHILD_PROCESS_INIT;
> >       int ret = -1;
> >       struct strbuf fingerprint_stdout = STRBUF_INIT;
> > -     struct strbuf **fingerprint;
> > +     struct string_list split = STRING_LIST_INIT_DUP;
> >       char *fingerprint_ret;
> >       const char *literal_key = NULL;
> >
> > @@ -845,13 +846,12 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> >               die_errno(_("failed to get the ssh fingerprint for key '%s'"),
> >                         signing_key);
> >
> > -     fingerprint = strbuf_split_max(&fingerprint_stdout, ' ', 3);
> > -     if (!fingerprint[1])
> > +     if (string_list_split(&split, fingerprint_stdout.buf, " ", 2) != 3)
>
> The original splits the thing into upto 3 pieces, but only complains
> if the second piece is NULL (i.e. we said "up to 3", but there was
> not even one place to split, and the request to split_max gave the
> one thing as one piece).  IOW, the original code will happily accept
> if the finterprint_stdout is split only into two, not three.
>
> The updated code asks to split at at most two places (yes, it is a
> confusing API, but if you split at two places, you will end up with
> three pieces), and insists that the split results in three pieces.
>
> So the rewrite tightens the error condition.
>
> Was the original code too loose in detecting an error, and does this
> patch tightens the condition "while at it"?  Or was the original
> code correct to expect that there are legitimate cases where the
> payload in finterprint_stdout only contains two pieces, and it was
> the right thing to do to accept when fingerprint[1] is not NULL but
> fingerprint[2] is NULL?
>
> This is a genuine question.  I haven't studied the code path to
> reach this point in the code flow, I don't know what the data in
> fingerprint_stdout is supposed to look like, so I do not know the
> answer to the question (in other words, it cannot be an oblique way
> to point out that the updated code is wrong or anything like that).

Yeah, I think the problem is that the commit message should explain how this whole issue is dealt with. Currently it talks about passing "2" to string_list_split() instead of passing "3" to strbuf_split_max(), but it says nothing about dealing with the return value from string_list_split().

It seems to me that fingerprint_stdout should contain something like:

4096 SHA256:PelI2esT2xZlv20wJJyYOkQsli5RMK79oJ2VxqYb2PA christian.couder@gmail.com (RSA)

and it looks like the 'key_size fingerprint_hash:fingerprint comment (key_type)' format is the standard `ssh-keygen -l` output.

So I think it's safe to say that we should expect `string_list_split(..., 2)` to return 3. That should work even if there is no comment in the key file.

But on the other hand, I think it's also acceptable to say that we just want to keep the same behavior as the original code and check its return value with `> 1` since we only need the second element resulting from the split.

> >               die_errno(_("failed to get the ssh fingerprint for key '%s'"),
> >                         signing_key);
> >
Bello Olamide· Oct 17, 2025, 10:07 UTC · re: Christian Couder · lore

Re: [Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split()

On Fri, 17 Oct 2025 at 10:15, Christian Couder <christian.couder@gmail.com> wrote:

Show 52 quoted lines
>
> On Thu, Oct 16, 2025 at 7:27 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Olamide Caleb Bello <belkid98@gmail.com> writes:
> >
> > > @@ -821,7 +822,7 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> > >       struct child_process ssh_keygen = CHILD_PROCESS_INIT;
> > >       int ret = -1;
> > >       struct strbuf fingerprint_stdout = STRBUF_INIT;
> > > -     struct strbuf **fingerprint;
> > > +     struct string_list split = STRING_LIST_INIT_DUP;
> > >       char *fingerprint_ret;
> > >       const char *literal_key = NULL;
> > >
> > > @@ -845,13 +846,12 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> > >               die_errno(_("failed to get the ssh fingerprint for key '%s'"),
> > >                         signing_key);
> > >
> > > -     fingerprint = strbuf_split_max(&fingerprint_stdout, ' ', 3);
> > > -     if (!fingerprint[1])
> > > +     if (string_list_split(&split, fingerprint_stdout.buf, " ", 2) != 3)
> >
> > The original splits the thing into upto 3 pieces, but only complains
> > if the second piece is NULL (i.e. we said "up to 3", but there was
> > not even one place to split, and the request to split_max gave the
> > one thing as one piece).  IOW, the original code will happily accept
> > if the finterprint_stdout is split only into two, not three.
> >
> > The updated code asks to split at at most two places (yes, it is a
> > confusing API, but if you split at two places, you will end up with
> > three pieces), and insists that the split results in three pieces.
> >
> > So the rewrite tightens the error condition.
> >
> > Was the original code too loose in detecting an error, and does this
> > patch tightens the condition "while at it"?  Or was the original
> > code correct to expect that there are legitimate cases where the
> > payload in finterprint_stdout only contains two pieces, and it was
> > the right thing to do to accept when fingerprint[1] is not NULL but
> > fingerprint[2] is NULL?
> >
> > This is a genuine question.  I haven't studied the code path to
> > reach this point in the code flow, I don't know what the data in
> > fingerprint_stdout is supposed to look like, so I do not know the
> > answer to the question (in other words, it cannot be an oblique way
> > to point out that the updated code is wrong or anything like that).
>
> Yeah, I think the problem is that the commit message should explain
> how this whole issue is dealt with. Currently it talks about passing
> "2" to string_list_split() instead of passing "3" to
> strbuf_split_max(), but it says nothing about dealing with the return
> value from string_list_split().
Yes, I will add this to the commit message too.
Show 12 quoted lines
>
> It seems to me that fingerprint_stdout should contain something like:
>
> 4096 SHA256:PelI2esT2xZlv20wJJyYOkQsli5RMK79oJ2VxqYb2PA
> christian.couder@gmail.com (RSA)
>
> and it looks like the 'key_size fingerprint_hash:fingerprint comment
> (key_type)' format is the standard `ssh-keygen -l` output.
>
> So I think it's safe to say that we should expect
> `string_list_split(..., 2)` to return 3. That should work even if
> there is no comment in the key file.
Yes, in this case fingerprint_stdout will contain something like:

2048 SHA256:BoQYpZX7zNZFOc9BSprkHoIgPhMTT1D5d5tqbwXZ1hA no comment (RSA)

Show 5 quoted lines
>
> But on the other hand, I think it's also acceptable to say that we
> just want to keep the same behavior as the original code and check its
> return value with `> 1` since we only need the second element
> resulting from the split.

Okay this is noted. Thank you.

Bello
Junio C Hamano· Oct 17, 2025, 18:47 UTC · re: Christian Couder · lore

Re: [Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split()

Christian Couder <christian.couder@gmail.com> writes:
Show 11 quoted lines
> It seems to me that fingerprint_stdout should contain something like:
>
> 4096 SHA256:PelI2esT2xZlv20wJJyYOkQsli5RMK79oJ2VxqYb2PA
> christian.couder@gmail.com (RSA)
>
> and it looks like the 'key_size fingerprint_hash:fingerprint comment
> (key_type)' format is the standard `ssh-keygen -l` output.
>
> So I think it's safe to say that we should expect
> `string_list_split(..., 2)` to return 3. That should work even if
> there is no comment in the key file.

I do not know why you or anybody can think it is safe from what you observed above, though. Who or which page of what manual told us that the key owner's identity part cannot be missing?

> But on the other hand, I think it's also acceptable to say that we
> just want to keep the same behavior as the original code and check its
> return value with `> 1` since we only need the second element
> resulting from the split.

Yes, as a code clean-up topic, I think it is the *only* acceptable thing to do. Finding the source to justify tightening of the rule to validate data to insist we have to see 3 pieces can be left to a separate topic once this series settles.

Thanks.
Bello Olamide· Oct 17, 2025, 10:53 UTC · re: Junio C Hamano · lore

Re: [Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split()

On Thu, 16 Oct 2025 at 18:27, Junio C Hamano <gitster@pobox.com> wrote:
Show 58 quoted lines
>
> Olamide Caleb Bello <belkid98@gmail.com> writes:
>
> > @@ -821,7 +822,7 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> >       struct child_process ssh_keygen = CHILD_PROCESS_INIT;
> >       int ret = -1;
> >       struct strbuf fingerprint_stdout = STRBUF_INIT;
> > -     struct strbuf **fingerprint;
> > +     struct string_list split = STRING_LIST_INIT_DUP;
> >       char *fingerprint_ret;
> >       const char *literal_key = NULL;
> >
> > @@ -845,13 +846,12 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> >               die_errno(_("failed to get the ssh fingerprint for key '%s'"),
> >                         signing_key);
> >
> > -     fingerprint = strbuf_split_max(&fingerprint_stdout, ' ', 3);
> > -     if (!fingerprint[1])
> > +     if (string_list_split(&split, fingerprint_stdout.buf, " ", 2) != 3)
>
> The original splits the thing into upto 3 pieces, but only complains
> if the second piece is NULL (i.e. we said "up to 3", but there was
> not even one place to split, and the request to split_max gave the
> one thing as one piece).  IOW, the original code will happily accept
> if the finterprint_stdout is split only into two, not three.
>
> The updated code asks to split at at most two places (yes, it is a
> confusing API, but if you split at two places, you will end up with
> three pieces), and insists that the split results in three pieces.
>
> So the rewrite tightens the error condition.
>
> Was the original code too loose in detecting an error, and does this
> patch tightens the condition "while at it"?  Or was the original
> code correct to expect that there are legitimate cases where the
> payload in finterprint_stdout only contains two pieces, and it was
> the right thing to do to accept when fingerprint[1] is not NULL but
> fingerprint[2] is NULL?
>
> This is a genuine question.  I haven't studied the code path to
> reach this point in the code flow, I don't know what the data in
> fingerprint_stdout is supposed to look like, so I do not know the
> answer to the question (in other words, it cannot be an oblique way
> to point out that the updated code is wrong or anything like that).
>
> >               die_errno(_("failed to get the ssh fingerprint for key '%s'"),
> >                         signing_key);
> >
> > -     fingerprint_ret = strbuf_detach(fingerprint[1], NULL);
> > -     strbuf_list_free(fingerprint);
> > +     fingerprint_ret = xstrdup(split.items[1].string);
> > +     string_list_clear(&split, 0);
> >       strbuf_release(&fingerprint_stdout);
>
> Since this code releases fingerprint_stdout before leaving, and
> returns a fresh copy of a split piece, it may make more sense to use
> string_list_split_in_place(), which does not have to allocate extra
> strings while it does its work, unlike string_list_split().
Thank you Junio for the review.
I will take a look at string_list_split_in_place().
Bello
Olamide Caleb Bello· Oct 16, 2025, 01:03 UTC · re: Olamide Caleb Bello · lore

[Outreachy PATCH v2 2/2] gpg-interface: use string_list_split() instead of strbuf_split_max()

In get_default_ssh_signing_key(), the default ssh signing key is retrieved in `key_stdout`, which is then split using strbuf_split_max() into two tokens

The string in `key_stdout` is then split using strbuf_split_max() into two tokens at a new line and the first token is returned as a `char *` and not a strbuf. This makes the function lack the use of strbuf API as no edits are performed on the split tokens.

Replace strbuf_split_max() with string_list_split() for simplicity.

Note that strbuf_split_max() uses `2` to indicate the number of tokens to extract from the string, while string_list_split() uses `1` to specify the number of times the split will be done on the string, so 1 gives 2 tokens as it is in the original instance.

Signed-off-by: Olamide Caleb Bello <belkid98@gmail.com>
---
Changes in v2
 - Reword the commit message for clarity
 - Replace the comment removed in v1
 - Change the test to ensure the number of tokens added to the list by
   string_list_split() equals 2
 - Add () to function names
 gpg-interface.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Show changes to gpg-interface.c +5 −5
diff --git a/gpg-interface.c b/gpg-interface.c
index 989dca7d14..ab7b8b46e5 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -862,7 +862,7 @@ static char *get_default_ssh_signing_key(void)
 	struct child_process ssh_default_key = CHILD_PROCESS_INIT;
 	int ret = -1;
 	struct strbuf key_stdout = STRBUF_INIT, key_stderr = STRBUF_INIT;
-	struct strbuf **keys;
+	struct string_list keys = STRING_LIST_INIT_DUP;
 	char *key_command = NULL;
 	const char **argv;
 	int n;
@@ -884,19 +884,19 @@ static char *get_default_ssh_signing_key(void)
 			   &key_stderr, 0);
 
 	if (!ret) {
-		keys = strbuf_split_max(&key_stdout, '\n', 2);
-		if (keys[0] && is_literal_ssh_key(keys[0]->buf, &literal_key)) {
+		if (string_list_split(&keys, key_stdout.buf, "\n", 1) == 2 &&
+			is_literal_ssh_key(keys.items[0].string, &literal_key)) {
 			/*
 			 * We only use `is_literal_ssh_key` here to check validity
 			 * The prefix will be stripped when the key is used.
 			 */
-			default_key = strbuf_detach(keys[0], NULL);
+			default_key = xstrdup(keys.items[0].string);
 		} else {
 			warning(_("gpg.ssh.defaultKeyCommand succeeded but returned no keys: %s %s"),
 				key_stderr.buf, key_stdout.buf);
 		}
 
-		strbuf_list_free(keys);
+		string_list_clear(&keys, 0);
 	} else {
 		warning(_("gpg.ssh.defaultKeyCommand failed: %s %s"),
 			key_stderr.buf, key_stdout.buf);
-- 
2.51.0.463.g79cf913ea9
Christian Couder· Oct 17, 2025, 07:58 UTC · re: Olamide Caleb Bello · lore

Re: [Outreachy PATCH v2 0/2] gpg-interface.c: use string_list_split() instead of strbuf_split_max()

On Thu, Oct 16, 2025 at 3:04 AM Olamide Caleb Bello <belkid98@gmail.com> wrote:
Show 10 quoted lines
>
> Commit 2efe707054 (wt-status: avoid strbuf_split*(), 2025-07-31) noticed
> that the array of strbufs that calls to strbuf_split*() provides are merely
> used to store the strings gotten from the split and no edit are
> done on these resulting strings making the strbuf_split*() unideal
> for this usecase, with the string_list_split*() being a more suitable option.
>
> The patch series by Junio Hamano can be seen in the link below.
>
> https://public-inbox.org/git/20250731225433.4028872-1-gitster@pobox.com/

This description is probably good enough as-is, but here are some comments that might help improve it if you want if you send a v3.

The way you explain things up to here, it might seem only one commit in that series is about avoiding strbuf_split*(). But in fact the commit you mention is the first one in that series which is named "do not overuse strbuf_split*()" and contains 11 patches.

So I think it would be a bit better if, instead of speaking about that commit first, this cover letter started with a link to that patch series and explained the purpose of the whole series. You may then mention one or more commits in the series as examples of commits where strbuf_split*() is replaced with string_list_split*() though if you want.

> This series continues on this path by replacing instances of
> strbuf_split_max() with string_list_split() where the string from the
> split is merely returned as char * and no edits are done on them.
Yeah, some commits in the series do that, but not all.
> Changes since v1
> ================
>  - Added commit reference and link to patch series for previous work
>  done on the subject

In a cover letter we are interested in the changes in the patch series since the previous version, not the changes in the cover letter. This is because the cover letter itself is not merged (except perhaps its first few sentences that might be reused in the merge commit, but this is more advanced, so don't take this into account for now) when a patch series is merged. So a cover letter is more about giving context to reviewers and inviting them to review the patch series.

So here it would be nice if there were things like:
  - a summary of the changes in the patch series since v1,
  - a range diff between v1 and v2,
  - a link to a CI platform where the v2 has been pushed and the CI
tests have been performed.

This would help make reviewer confident that the series is in a much better shape compared to v1 and reviewers' comments on v1 have been taken into account.

Thanks.
Bello Olamide· Oct 17, 2025, 09:54 UTC · re: Christian Couder · lore

Re: [Outreachy PATCH v2 0/2] gpg-interface.c: use string_list_split() instead of strbuf_split_max()

On Fri, 17 Oct 2025 at 08:58, Christian Couder <christian.couder@gmail.com> wrote:

Show 27 quoted lines
>
> On Thu, Oct 16, 2025 at 3:04 AM Olamide Caleb Bello <belkid98@gmail.com> wrote:
> >
> > Commit 2efe707054 (wt-status: avoid strbuf_split*(), 2025-07-31) noticed
> > that the array of strbufs that calls to strbuf_split*() provides are merely
> > used to store the strings gotten from the split and no edit are
> > done on these resulting strings making the strbuf_split*() unideal
> > for this usecase, with the string_list_split*() being a more suitable option.
> >
> > The patch series by Junio Hamano can be seen in the link below.
> >
> > https://public-inbox.org/git/20250731225433.4028872-1-gitster@pobox.com/
>
> This description is probably good enough as-is, but here are some
> comments that might help improve it if you want if you send a v3.
>
> The way you explain things up to here, it might seem only one commit
> in that series is about avoiding strbuf_split*(). But in fact the
> commit you mention is the first one in that series which is named "do
> not overuse strbuf_split*()" and contains 11 patches.
>
> So I think it would be a bit better if, instead of speaking about that
> commit first, this cover letter started with a link to that patch
> series and explained the purpose of the whole series. You may then
> mention one or more commits in the series as examples of commits where
> strbuf_split*() is replaced with string_list_split*() though if you
> want.

Yes, this approach would be better. Thank you

Show 6 quoted lines
>
> > This series continues on this path by replacing instances of
> > strbuf_split_max() with string_list_split() where the string from the
> > split is merely returned as char * and no edits are done on them.
>
> Yeah, some commits in the series do that, but not all.
Yes I will reword this too.
Show 25 quoted lines
>
> > Changes since v1
> > ================
> >  - Added commit reference and link to patch series for previous work
> >  done on the subject
>
> In a cover letter we are interested in the changes in the patch series
> since the previous version, not the changes in the cover letter. This
> is because the cover letter itself is not merged (except perhaps its
> first few sentences that might be reused in the merge commit, but this
> is more advanced, so don't take this into account for now) when a
> patch series is merged. So a cover letter is more about giving context
> to reviewers and inviting them to review the patch series.
>
> So here it would be nice if there were things like:
>
>   - a summary of the changes in the patch series since v1,
>   - a range diff between v1 and v2,
>   - a link to a CI platform where the v2 has been pushed and the CI
> tests have been performed.
>
> This would help make reviewer confident that the series is in a much
> better shape compared to v1 and reviewers' comments on v1 have been
> taken into account.
>

Thank you very much for the review and suggestions. I will reorganise and send a corrected v3.

Bello.

← back to recent threads