Re: [Alt. PATCH] ls-remote: deprecate -h as short for --heads
From: Junio C Hamano <hidden>
Date: 2017-10-20 05:35:43
Jeff King [off-list ref] writes:
<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".