On Wed, Oct 16, 2013 at 09:04:32AM +0200, Johannes Sixt wrote: > > Yes, another possibility in that vein would be to teach rev-parse > > --parseopt an OPTIONS_LONG_STICKED output format, and then parse with > > Aren't you people trying to solve something that can't besolved? What does > > git commit -S LICENSE > > mean? Commit the index and sign with the key-id "LICENSE" or commit just > the file "LICENSE" with the default key-id? It means the latter. Because the argument is optional, you must use the "sticked" form: git commit -SLICENSE If the caller does not know whether the argument is optional or not, they should use the sticked form to be on the safe side. The problem, as I understand it, arises from the fact that shell scripts can use "git rev-parse --parseopt" to check and normalize their arguments. So for example: # pretend we got "-bs" on our command line set -- -bs git rev-parse --parseopt -- "$@" <<\EOF usage... -- b! the "b" option s! the "s" option EOF would produce: set -- -b -s -- The latter is much easier to parse in the shell, because options are split, it ends with "--", etc. But what is the normalized form for an optional argument? It either needs to be consistently "sticked" or "unsticked", either: set -- -S '' -- ;# default set -- -S 'foo' -- ;# not default or set -- -S -- ;# default set -- -Sfoo -- ;# not default so that reading the normalized form is unambiguous. -Peff -- 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