Re: Commands using -h as an option don't work consistently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On May 29, 2024, at 5:22 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 
> This is very much deliberate design.  I think in these cases we make
> an unambiguous longhand (e.g. "--heads" we see above) available, or
> you can explicitly say the remote, i.e. "git ls-remote -h origin",
> and that has been the officially accepted "solution".

Yeah, and that totally makes sense. This bit me because I was programmatically generating git commands that would sometimes call ls-remote with no options, sometimes asking only for heads, sometimes only for tags.... and was baffled for longer than I want to admit why it wasn't working consistently. I thought the usage was being shown because I was doing something wrong. My first thought was it was showing me the help message because if you ask for heads you must also use some other option along with it. It didn't occur to me that -h and --heads would behave differently.

> Let's see what improvements you bring to the table.
> 
>> The options I see:
>> 
>> 1) Fix -h handling and add ignores and fixes where possible to the
>> failing tests and try to not use -h as an option for anything new.
> 
> I do not quite understand the former half, but "try not to use -h
> for new things" is a very good idea and it is pretty much what we
> have been doing.

Sorry, let me rephrase that.  1) Apply the fix I was proposing to make it so that the command's -h usage has precedence over showing the usage. Any tests that break because of that which don't have a plausible fix mark as "# TODO known breakage" like several other commands have because they aren't generating usage output correctly for one reason or another.


> We can certainly add support for "-?", but the behaviour when "-?"
> is not used (and when "-h" is used) would not have to change from
> the current behaviour, and that would still be serviceable, I
> presume?
> 

That was proposing making -? unconditionally show usage, if a command uses -h give that priority over showing usage even if it's the only option, but leaving -h to still show usage everywhere else, and changing all the tests to use -? Instead of -h so the tests can unambiguously request the usage.

I think that covers every case then. If a command advertises -h it always works, it falls back to showing usage if there is no -h, and tests can use -? which will always show usage and we can even make parse-options reject anyone's attempt to use -? as an option in the future so this doesn't come up again in 10 years.

> We actually do not have to *add* support for "-?", as it comes with
> parse-options for free ;-)
> 
>    $ git ls-remote -\?
>    error: unknown switch '?'
>    usage: git ls-remote ...
> ... the same "ls-remote -h" output given here ...

That *almost* works, except some tests would have to be modified because they don't like that error line in there, but that is super clever! It would be pretty trivial to make parse-options deliberately spit the usage out without an error though in the -? case.








[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux