Re: [PATCH 2/2] config/remote.txt: improve wording for 'remote.<name>.followRemoteHEAD'

[Philippe Blain <levraiphilippeblain@gmail.com>]

Hi Bence,

Le 2025-02-14 à 17:05, Bence Ferdinandy a écrit :
> 
> On Fri Feb 14, 2025 at 18:36, Philippe Blain via GitGitGadget <gitgitgadget@gmail.com> wrote:
>> From: Philippe Blain <levraiphilippeblain@gmail.com>
>>
>> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
>> ---
>>  Documentation/config/remote.txt | 12 ++++++------
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/config/remote.txt b/Documentation/config/remote.txt
>> index 1b9814e8aa4..25fe219d103 100644
>> --- a/Documentation/config/remote.txt
>> +++ b/Documentation/config/remote.txt
>> @@ -110,12 +110,12 @@ the values inherited from a lower priority configuration files (e.g.
>>  remote.<name>.followRemoteHEAD::
>>  	How linkgit:git-fetch[1] should handle updates to `remotes/<name>/HEAD`.
>>  	The default value is "create", which will create `remotes/<name>/HEAD`
>> -	if it exists on the remote, but not locally, but will not touch an
>> -	already existing local reference. Setting to "warn" will print
>> -	a message if the remote has a different value, than the local one and
>> +	if it exists on the remote, but not locally; this will not touch an
>> +	already existing local reference. Setting it to "warn" will print
>> +	a message if the remote has a different value than the local one;
>>  	in case there is no local reference, it behaves like "create".
>>  	A variant on "warn" is "warn-if-not-$branch", which behaves like
>>  	"warn", but if `HEAD` on the remote is `$branch` it will be silent.
>> -	Setting to "always" will silently update it to the value on the remote.
>> -	Finally, setting it to "never" will never change or create the local
>> -	reference.
>> +	Setting it to "always" will silently update `remotes/<name>/HEAD` to
>> +	the value on the remote.  Finally, setting it to "never" will never
>> +	change or create the local reference.
> 
> I'm personally not a huge fan of semicolons, but I do agree that the text does
> not flow particularly well. Wouldn't it actually make sense to format this as
> a list, with an entry for each option? The would probably also help in quickly
> parsing how many options there are.

I think lists are a good idea in general, but since there is no uniformity with regards
to that in the rest of the documentation, I would keep it as-is for this series.

Thanks,

Philippe.