Re: [ANNOUNCE] Git v2.0.0-rc0

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 22, 2014, 21:26 UTC
Message-ID: <xmqqy4yx2gz9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140422210002.GC15516@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 36 quoted lines

> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> Hm, perhaps we should introduce a 'no-prefix' option to work around
>>> this.
> [...]
>>> That way, normal usage of --prefix would still be consistent with
>>> other git commands that prefer the form with argument attached
>>> (--prefix=foo, not --prefix foo; see gitcli(7)).
>>>
>>> Thoughts?
>>
>> I do not think that it is a good idea to use "--no-anything" for
>> something that is not a boolean.
>
> Do you mean it is a bad idea to support or a bad idea to make use of
> such support?
>
> I suggested --no- for consistency with current git commands that use
> parseopt.  But on second thought, I agree that it be confusing for
>
> 	--prefix=foo --no-prefix
>
> to mean something different from no --prefix parameter at all.
>
> The documentation says
>
> 	--prefix=<prefix>
>
> 		...
>
> 		Before Git 2.0, the default prefix was "" (no prefix).
> 		This meant that ...
>
> which suggests that I can use --prefix="" to mean no prefix.  Perhaps
> it needs a note to suggest using '--prefix ""' instead?

Is there another --option that takes an arbitrary user string that could be an empty string (or will there be one in the future)? If that is the case, a better alternative might be to add an comment to say that those with older Getopt::Long may have to use --option "" instead of the --option="" form for any option whose value happens to be an empty string to work around the command parser bug.