Am 20.10.2017 um 07:35 schrieb Junio C Hamano: > Jeff King <p...@peff.net> writes: > >> <shrug> It seems weird and inconsistent to me that the meaning of "-h" >> depends on the position and presence of other unrelated options.
The position is relevant with parse-options for *each* flag for a different reason as well: You can't put a flag after a non-flag. I find that more annoying, as it slightly but noticeable slows down adding a flag to a previous command by requiring to navigate to the middle of the line. (I guess I should train myself to use Meta-b for going back one word more often..) > I may be biased as every time I think about this one, the first one > that comes to my mind is how "grep -h" (not "git grep", but GNU > grep) behaves. Yes, "-h" means something else, but by itself, the > command does not make sense, and "ls-remote -h" is an exception to > the rule: most sane commands do not have a sensible semantics when > they take only "-h" and nothing else. And even for ls-remote it is > true only when you try to be extra lazy and do not say which remote > you are asking. > > And that is why I think "'cmd -h" and nothing else consistently > gives help" may overall be positive in usability, than a rule that > says "'cmd -h' is for short-help unless -h means something else for > the command". FWIW, I use "-?" for that everywhere. I have yet to find a command or environment where it does something dangerous. René
