Re: [Alt. PATCH] ls-remote: deprecate -h as short for --heads

From: René Scharfe <l.s.r@web.de>
Date: Oct 21, 2017, 10:14 UTC
Message-ID: <437f4e47-fcb1-ff8c-3c5a-fa9a5cecedfe@web.de>
In-Reply-To: <xmqq7evqidp3.fsf@gitster.mtv.corp.google.com>

Am 20.10.2017 um 07:35 schrieb Junio C Hamano:

> Jeff King <peff@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..)

Show 13 quoted lines

> 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é