On 17 October 2017 at 17:39, René Scharfe <l....@web.de> wrote: > Stop advertising -h as the short equivalent of --heads, because it's > used for showing a short help text for almost all other git commands. > Since the ba5f28bf79 (ls-remote: use parse-options api) it has only > been working when used together with other parameters anyway. > > Signed-off-by: Rene Scharfe <l....@web.de> > --- > That would be step on the way towards more consistent command line > switches, in the same vein as d69155119 (t0012: test "-h" with > builtins).
FWIW, my first inclination would be to go with a patch like this instead of the other two (where you introduce an exception so that git ls-remote -h does not display the usage). ba5f28bf79 was in 2.8.0. That's 18 months ago. Not an eternity, but still some time ago. Not fixing this regression has an obvious downside, but there's also a downside to adding the exception. As long as a lone -h may give the usage or do something else entirely, then -- put bluntly -- to know whether you can request the usage with git foo -h without risk of messing up your repo, you'll need to look up the usage some other way. At which point you've solved your original problem, without -h. Of course, we could promise that -h will give the usage or, in case of historical wart(s), do something harmless. But it seems a bit awkward, and might limit the perceived usefulness/safeness or -h. > diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt > index 5f2628c8f8..898836a111 100644 > --- a/Documentation/git-ls-remote.txt > +++ b/Documentation/git-ls-remote.txt > @@ -21,7 +21,6 @@ commit IDs. > > OPTIONS > ------- > --h:: > --heads:: > -t:: > --tags:: Do we want to document -h as a deprecated alias, so that people have a slightly larger chance of noticing and adapting?
