"D. Ben Knoble" <ben.knoble+github@xxxxxxxxx> 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.
