Hi Junio,
On 07/04/2019 14:43, Junio C Hamano wrote:
Duy Nguyen <pclo...@gmail.com> writes:
Phew... I didn't break anything!
That behavior has been gone since 2c6b6d9f7d (help: make option --help
open man pages only for Git commands, 2016-08-26). Ralf did not
mention why he thought "git <concept> --help" was a bad idea. But it
was considered a bug by Junio [1]
[1]
https://public-inbox.org/git/CAPc5daXicjUDi6B-MA8Sn=_UZ_jHvc8SE4ZXt2dHbbDQkD7=w...@mail.gmail.com/
I do not think you are reading me correctly.
Yes, I do consider that "git foo --help" that does not say "there is
no subcomand 'foo' in Git suite" is a bug. But that is only for
'foo' that is clearly meant as a command.
I do not imagine anybody labelling "git help glossary" as a bug.
I am fairly neutral about "git glossary --help". I personally would
not ask git like so, as "glossary" is clearly not a command name,
and the "--help" option is clearly meant as an option to the
subcommand, which means that the request logically does not make
much sense.
But unlike "git foo --help", if the word that ought to name a
subcommand instead names a known concept, e.g. "glossary", I do not
think it is too bad if we DWIMmed what the user meant to say,
i.e. turning "git glossary --help" into "git help glossary".
Given the earlier report that started the thread Duy linked, I guess
there will need to be a balance between the two expectations.
The DWIMming may need to both report that it's not a command, but then
offer the concept guide as the primary target if correct, or perhaps as
one of the alternate "commands" if closely named to a guide (e.g.
revisions vs revision).
One of the issues back then was the lack of a complete list of 'guides'
to check against, so the badly spelt command logic wasn't brought into play.
--
Philip
