From: Philip Oakley Date: Sun, 07 Apr 2019 22:42:39 GMT Subject: Re: git glossary --help ? Message-ID: <3de9d8bc-f9d1-bf09-def6-71e5ed418225@iee.org> In-Reply-To: Hi Junio, On 07/04/2019 14:43, Junio C Hamano wrote: > Duy Nguyen 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 --help" was a bad idea. But it >> was considered a bug by Junio [1] >> >> [1] https://public-inbox.org/git/CAPc5daXicjUDi6B-MA8Sn=_UZ_jHvc8SE4ZXt2dHbbDQkD7=WA@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