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

From: Jeff King <peff@peff.net>
Date: Oct 21, 2017, 07:16 UTC
Message-ID: <20171021071613.yynmigxiixnqggik@sigill.intra.peff.net>
In-Reply-To: <xmqq7evqidp3.fsf@gitster.mtv.corp.google.com>

On Fri, Oct 20, 2017 at 02:35:36PM +0900, Junio C Hamano wrote:

Show 8 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.

Yeah, I have to admit "grep -h" is a lot more compelling, since it matches normal grep. And I've used "grep -h" many times without thinking about it, simply because the rule just falls out naturally there (there's nothing possible to do without a regex argument, so we'd show the usage either way).

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

Yeah, I was shooting more for "let's avoid assigning -h to things". But that's not really possible if we want to be consistent with upstream grep, which is probably more important.

I think you've convinced me.

-Peff