Jonathan Nieder <jrnie...@gmail.com> writes:
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnie...@gmail.com> writes:
>>> Hm, perhaps we should introduce a 'no-prefix' option to work around
>>> 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)).
>> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html