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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2017, 01:04 UTC
Message-ID: <xmqqlgk6iq94.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171019203249.76uu3b6ferquitcr@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

> On Thu, Oct 19, 2017 at 08:26:47PM +0200, René Scharfe wrote:
>
>> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
>> index 5f2628c8f8..82622e7fbc 100644
>> --- a/Documentation/git-ls-remote.txt
>> +++ b/Documentation/git-ls-remote.txt
>> @@ -29,6 +29,9 @@ OPTIONS
>>  	These options are _not_ mutually exclusive; when given
>>  	both, references stored in refs/heads and refs/tags are
>>  	displayed.
>> ++
>> +*NOTE*: -h without any other parameters shows a short help text instead
>> +of any refs.
>
> Yuck. This "we only treat -h as special in certain cases" rule is
> sufficiently magical that I don't think we want to advertise and lock
> ourselves into it.

Hmph. I think it is way too late to be worried about "locked into" the convention---hasn't the "git cmd -h" been with us forever?

Besides, I personally feel that there is nothing magical in the rule that is "we always treat 'git $cmd -h' as asking for short help, but individual subcommand may choose to use -h for, perhaps to be compatible with other tools and conventions, in other situations".