Re: [PATCH 4/4] builtins: show help on "-h"/"--help-all" with more than 2 arguments left

[Junio C Hamano <gitster@pobox.com>]

"D. Ben Knoble" <ben.knoble+github@gmail.com> writes:

> When asking for short help on a previous command, the user may use their
> shell history to recall a command like
>
>     git rebase new-base
>
> Then inserting "-h" after "rebase" doesn't yield the help; make it so.

I doubt this is a good idea for at least two reasons.

 * As "git help cli" says, we should be discouraging, not
   encouraging peope to say "git rebase new-base -h".

 * "git rebase -h new-base" that shows help is probably a bug (think
   what should happen with s/rebase/grep/) in the first place.

If anything, we probably should fix the "-h" codepath to

 - react and do the short-help only when "-h" is the only command
   line option; with argument, it should probably barf, saying "-h
   does not take an argument".

 - if "-h" resulted in reported an alias, it should stop there.
   E.g. "git -c alias.x=ls-files x -h" would currently invoke "git
   ls-files -h" after reporting that 'x' is aliased to 'ls-files'.
   If the alias is to one of our commands, it is not too risky, but
   otherwise we should not assume it is safe to append "-h" to the
   underlying command and run it.  Imagine

   $ git -c alias.x='!echo rm -rf .' x -h

   and worse yet, if your alias did not have "echo" in it ;-)???

The only end-user expectation we can safely assume is when they
say,
 
   $ git frotz -h

is that they would get a help on 'frotz' without doing any harm.  
If frotz is an alias to some external command, for which we have no
idea what it would do when we run it with "-h" appended to the
command line, the user would be in a lot of pain if the aliased
operation is destructive.