Subject: Re: [PATCH v2 4/7] string-list: optionally trim string pieces split by string_list_split*()

From: Junio C Hamano <[email-masked]>
Date: Fri, 01 Aug 2025 09:26:37 -0700

Patrick Steinhardt <[email-masked]> writes:

> One issue I have with the `_f` suffix is that I immediately jumped
> to "formatting string". I think in other places we use `_ext` as a
> suffix.

It stands for "with flags".  I've seen _with_options and _extended
also used.  This is like oid_object_info_extended() that has a
variant oid_object_info() that is a simpler and less capable wrapper
for common use cases.  None of these overly long names are my
favourites X-<.

With brief inspection, many _ext() in midx.c are more like helpers
that deal with a class of files with .$ext for various extensions;
they are not the primary interface to external callers, and many are
extern only because the code is spread across midx. and midx-write.c
instead of being in a single compilation unit.

>> diff --git a/string-list.h b/string-list.h
>> index 6c8650efde..ee9922af67 100644
>> --- a/string-list.h
>> +++ b/string-list.h
>> @@ -281,4 +281,14 @@ int string_list_split(struct string_list *list, const char *string,
>>   */
>>  int string_list_split_in_place(struct string_list *list, char *string,
>>  			       const char *delim, int maxsplit);
>> +
>> +/* trim() resulting string piece before adding it to the list */
>> +#define STRING_LIST_SPLIT_TRIM 01
>
> Another nit: I think nowadays we more often use enums to introduce such
> flags, where the benefit is improved grouping. Also, I think having
> `(1 << 0)` as value is slightly more readable.

OK, let's update that.  Thanks.