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

From: Jeff King <peff@peff.net>
Date: Oct 20, 2017, 03:05 UTC
Message-ID: <20171020030524.4xlwrdag7e4gzg7s@sigill.intra.peff.net>
In-Reply-To: <xmqqlgk6iq94.fsf@gitster.mtv.corp.google.com>

On Fri, Oct 20, 2017 at 10:04:23AM +0900, Junio C Hamano wrote:

Show 6 quoted lines

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

I guess. I still find it pretty nasty (not that "-h" works for help, but that it can override the normal usage).

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

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

-Peff