Jonathan Nieder <> writes:

> Junio C Hamano wrote:
>> Jonathan Nieder <> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to