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@xxxxxxxxx> wrote: >> From: Philippe Blain <levraiphilippeblain@xxxxxxxxx> >> >> Signed-off-by: Philippe Blain <levraiphilippeblain@xxxxxxxxx> >> --- >> 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.
