Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Jonathan Nieder <jrnieder@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html