Documentation/git-merge: at least one <remote> not two
PATCH 1/1 Documentation/git-merge: at least one <remote> not two
Make SYNOPSIS match usage message
--- Documentation/git-merge.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Documentation/git-merge.txt +1 -1
@@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]... - [-m <msg>] <remote> <remote>... + [-m <msg>] <remote>... 'git merge' <msg> HEAD <remote>... DESCRIPTION
Signature · 1 line
1.6.0.6
Quoted 12 lines · [email protected] writes:
Make SYNOPSIS match usage message
Signed-off-by jidanni <[email protected]>--- Documentation/git-merge.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)Documentation/git-merge.txt +0
-0
Documentation/git-merge.txt SYNOPSIS · line 14
Quoted 6 lines
Documentation/git-merge.txt +1
-1@@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]... - [-m <msg>] <remote> <remote>... + [-m <msg>] <remote>... 'git merge' <msg> HEAD <remote>...
The original uses ellipses for the first-class UI syntax as "zero or more", while it means "one or more" in the description for the original syntax, which is inconsistent, and you are matching them by making both use "one or more" interpretation.
Two issues:
* Are there similar breakages like this in the documentation and the usage text? It would be a good idea to make the ellipses to mean the same thing everywhere, and a janitorial patch series that would fix the "ellipses" breakage (and nothing else) may be a good thing to have. But before going that route...
* Is it a good idea to standardize on "one or more" semantics? I suspect we would rather want to standardize on "zero or more", because it would be more natural to say:
$ git diff [--] <paths>...
to mean "You can give paths if you want to but you do not have to". If ellipses meant "one or more", you have to say this instead:
$ git diff [--] [<paths>...]
While I prefer "zero or more" because I think it is more logical, if the preparatory study for the first issue reveals that we use "one or more" a lot more often, it might be easier to standardize on that interpretation.
Oh, you also need to give ellipses to the usage string for the original syntax in builtin-merge.c to match SYNOPSIS and usage string.
Thanks.
Quoted 10 lines · Junio C Hamano
* Is it a good idea to standardize on "one or more" semantics? I suspect we would rather want to standardize on "zero or more", because it would be more natural to say:
$ git diff [--] <paths>...to mean "You can give paths if you want to but you do not have to". If ellipses meant "one or more", you have to say this instead:
$ git diff [--] [<paths>...]
For what it is worth, I have always understood "..." to mean "more of the preceding", meaning "one or more". That is your first example above.
Zero or more is your second syntax above, because the whole thing is in brackets, and hence completely optional.
In regex terms (to me anyway):
a? == [a] a+ == a... a* == [a...]