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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2025, 16:26 UTC
Message-ID: <xmqq4iurnh36.fsf@gitster.g>
In-Reply-To: <aIx_HIjWEDx9pNW2@pks.im>

Patrick Steinhardt <ps@pks.im> 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.

Show 15 quoted lines

>> 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.