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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2017, 05:35 UTC
Message-ID: <xmqq7evqidp3.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171020030524.4xlwrdag7e4gzg7s@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> <shrug> It seems weird and inconsistent to me that the meaning of "-h"
> depends on the position and presence of other unrelated options. Maybe
> it's just me. I know _why_ it's that way, but this seems like one of
> those weird corners of the interface that end up confusing people and
> giving Git's interface the reputation of being full of mysterious
> inconsistencies. I suspect one of the reasons nobody has complained
> about it is that "ls-remote" is not commonly used, and "ls-remote -h"
> less so (I didn't even know it was there until this conversation).

Technically, yes, it may be weird.

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".