[PATCH 1/1] doc/gitcli: minor fixes

[PATCH 1/1] doc/gitcli: minor fixes

[Dirk Gouders]

Fix three details in the gitcli documentation:

Use plural where appropriate and imperative form when rules are
listed.

Signed-off-by: Dirk Gouders <dirk@gouders.net>
---
 Documentation/gitcli.adoc | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/gitcli.adoc b/Documentation/gitcli.adoc
index 9c4598e29c..6b0a58938a 100644
--- a/Documentation/gitcli.adoc
+++ b/Documentation/gitcli.adoc
@@ -8,7 +8,7 @@ gitcli - Git command-line interface and conventions
 DESCRIPTION
 -----------
 
-This manual describes the convention used throughout Git CLI.
+This manual describes the conventions used throughout Git CLI.
 
 Many commands take revisions (most often "commits", but sometimes
 "tree-ish", depending on the context and command) and paths as their
@@ -28,7 +28,7 @@ arguments.  Here are the rules:
    `v1.0` and `v2.0` are revisions and `arch/x86` and `include/asm-x86`
    are paths.
 
- * When an argument can be misunderstood as either a revision or a path,
+ * When arguments can be misunderstood as either a revision or a path,
    they can be disambiguated by placing `--` between them.
    E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work
    tree.  Please show changes between the version I staged in the index
@@ -76,8 +76,8 @@ you will.
 Here are the rules regarding the "flags" that you should follow when you are
 scripting Git:
 
- * Splitting short options to separate words (prefer `git foo -a -b`
-   to `git foo -ab`, the latter may not even work).
+ * Split short options to separate words: prefer `git foo -a -b`
+   to `git foo -ab` (the latter may not even work).
 
  * When a command-line option takes an argument, use the 'stuck' form.  In
    other words, write `git foo -oArg` instead of `git foo -o Arg` for short
-- 
2.55.0

Re: [PATCH 1/1] doc/gitcli: minor fixes

[Junio C Hamano]

Dirk Gouders <dirk@gouders.net> writes:

> -This manual describes the convention used throughout Git CLI.
> +This manual describes the conventions used throughout Git CLI.

OK.

> @@ -28,7 +28,7 @@ arguments.  Here are the rules:
>     `v1.0` and `v2.0` are revisions and `arch/x86` and `include/asm-x86`
>     are paths.
>  
> - * When an argument can be misunderstood as either a revision or a path,
> + * When arguments can be misunderstood as either a revision or a path,
>     they can be disambiguated by placing `--` between them.

I would rather have left the subject as-is, and then rewrote the
conclusion part to "it can be disambiguated by placing `--` before
or arter it".  Once you start talking about multiple arguments, you
would have to also reorder them so that all revs come first, then
'--', and then all paths. 

> @@ -76,8 +76,8 @@ you will.
>  Here are the rules regarding the "flags" that you should follow when you are
>  scripting Git:
>  
> - * Splitting short options to separate words (prefer `git foo -a -b`
> -   to `git foo -ab`, the latter may not even work).
> + * Split short options to separate words: prefer `git foo -a -b`
> +   to `git foo -ab` (the latter may not even work).

OK.

Thanks.

Re: [PATCH 1/1] doc/gitcli: minor fixes

[Dirk Gouders]

On Sat, Nov 14 2026, Junio C Hamano wrote:

> Dirk Gouders <dirk@gouders.net> writes:
>
>> -This manual describes the convention used throughout Git CLI.
>> +This manual describes the conventions used throughout Git CLI.
>
> OK.
>
>> @@ -28,7 +28,7 @@ arguments.  Here are the rules:
>>     `v1.0` and `v2.0` are revisions and `arch/x86` and `include/asm-x86`
>>     are paths.
>>  
>> - * When an argument can be misunderstood as either a revision or a path,
>> + * When arguments can be misunderstood as either a revision or a path,
>>     they can be disambiguated by placing `--` between them.
>
> I would rather have left the subject as-is, and then rewrote the
> conclusion part to "it can be disambiguated by placing `--` before
> or arter it".  Once you start talking about multiple arguments, you
> would have to also reorder them so that all revs come first, then
> '--', and then all paths. 

Thank you for the quick review.

Yes, there were two possible fixes for this second detail.
I will send a v2 according to your suggestion.

Regards,

Dirk

>> @@ -76,8 +76,8 @@ you will.
>>  Here are the rules regarding the "flags" that you should follow when you are
>>  scripting Git:
>>  
>> - * Splitting short options to separate words (prefer `git foo -a -b`
>> -   to `git foo -ab`, the latter may not even work).
>> + * Split short options to separate words: prefer `git foo -a -b`
>> +   to `git foo -ab` (the latter may not even work).
>
> OK.
>
> Thanks.

[PATCH v2] doc/gitcli: minor fixes

[Dirk Gouders]

Fix three details in the gitcli documentation:

Use plural/singular where appropriate and imperative form when rules
are listed.

Signed-off-by: Dirk Gouders <dirk@gouders.net>
---
 Documentation/gitcli.adoc | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/gitcli.adoc b/Documentation/gitcli.adoc
index 9c4598e29c..454c482a50 100644
--- a/Documentation/gitcli.adoc
+++ b/Documentation/gitcli.adoc
@@ -8,7 +8,7 @@ gitcli - Git command-line interface and conventions
 DESCRIPTION
 -----------
 
-This manual describes the convention used throughout Git CLI.
+This manual describes the conventions used throughout Git CLI.
 
 Many commands take revisions (most often "commits", but sometimes
 "tree-ish", depending on the context and command) and paths as their
@@ -29,7 +29,7 @@ arguments.  Here are the rules:
    are paths.
 
  * When an argument can be misunderstood as either a revision or a path,
-   they can be disambiguated by placing `--` between them.
+   it can be disambiguated by placing `--` before or after it.
    E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work
    tree.  Please show changes between the version I staged in the index
    and what I have in the work tree for that file", not "show the difference
@@ -76,8 +76,8 @@ you will.
 Here are the rules regarding the "flags" that you should follow when you are
 scripting Git:
 
- * Splitting short options to separate words (prefer `git foo -a -b`
-   to `git foo -ab`, the latter may not even work).
+ * Split short options to separate words: prefer `git foo -a -b`
+   to `git foo -ab` (the latter may not even work).
 
  * When a command-line option takes an argument, use the 'stuck' form.  In
    other words, write `git foo -oArg` instead of `git foo -o Arg` for short
-- 
2.55.0