aboutsummaryrefslogtreecommitdiff
path: root/parse-options.c
Commit message (Collapse)AuthorAge
* parse-options: print "fatal:" before usage_msg_opt()Jeff King2016-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Programs may use usage_msg_opt() to print a brief message followed by the program usage, and then exit. The message isn't prefixed at all, though, so it doesn't match our usual error output and is easy to overlook: $ git clone 1 2 3 Too many arguments. usage: git clone [<options>] [--] <repo> [<dir>] -v, --verbose be more verbose -q, --quiet be more quiet --progress force progress reporting -n, --no-checkout don't create a checkout --bare create a bare repository [...and so on for another 31 lines...] It looks especially bad when the message starts with an option, like: $ git replace -e -e needs exactly one argument usage: git replace [-f] <object> <replacement> or: git replace [-f] --edit <object> [...etc...] Let's put our usual "fatal:" prefix in front of it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options.c: make OPTION_COUNTUP respect "unspecified" valuesPranit Bauva2016-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OPT_COUNTUP() merely increments the counter upon --option, and resets it to 0 upon --no-option, which means that there is no "unspecified" value with which a client can initialize the counter to determine whether or not --[no]-option was seen at all. Make OPT_COUNTUP() treat any negative number as an "unspecified" value to address this shortcoming. In particular, if a client initializes the counter to -1, then if it is still -1 after parse_options(), then neither --option nor --no-option was seen; if it is 0, then --no-option was seen last, and if it is 1 or greater, than --option was seen last. This change does not affect the behavior of existing clients because they all use the initial value of 0 (or more). Note that builtin/clean.c initializes the variable used with OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set to either 0 or 1 by reading the configuration before the code calls parse_options(), i.e. as far as parse_options() is concerned, the initial value of the variable is not negative. To test this behavior, in test-parse-options.c, "verbose" is set to "unspecified" while quiet is set to 0 which will test the new behavior with all sets of values. Helped-by: Jeff King <peff@peff.net> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: allow -h as a short optionRené Scharfe2015-11-20
| | | | | | | | | | | Let callers provide their own handler for the short option -h even without the flag PARSE_OPT_NO_INTERNAL_HELP, but call the internal handler (showing usage information) if that is the only parameter. Implement the first part by checking for -h only if parse_short_opt() can't find it and returns -2. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net>
* parse-options: inline parse_options_usage() at its only remaining callerRené Scharfe2015-11-20
| | | | | Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net>
* parse-options: deduplicate parse_options_usage() callsRené Scharfe2015-11-20
| | | | | | | | Avoid long lines and repeating parse_options_usage() calls with their duplicate parameters by providing labels with speaking names to jump to. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net>
* parse-options: move unsigned long option parsing out of pack-objects.cCharles Bailey2015-06-22
| | | | | | | | | | | | | | | | | | | The unsigned long option parsing (including 'k'/'m'/'g' suffix parsing) is more widely applicable. Add support for OPT_MAGNITUDE to parse-options.h and change pack-objects.c use this support. The error behavior on parse errors follows that of OPT_INTEGER. The name of the option that failed to parse is reported with a brief message describing the expect format for the option argument and then the full usage message for the command invoked. This differs from the previous behavior for OPT_ULONG used in pack-objects for --max-pack-size and --window-memory which used to display the value supplied in the error message and did not display the full usage message. Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/parseopt-verify-short-name'Junio C Hamano2014-09-19
|\ | | | | | | | | | | | | | | Add checks for a common programming mistake to assign the same short option name to two separate options to help developers. * jc/parseopt-verify-short-name: parse-options: detect attempt to add a duplicate short option name
| * parse-options: detect attempt to add a duplicate short option nameJunio C Hamano2014-09-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is easy to overlook an already assigned single-letter option name and try to use it for a new one. Help the developer to catch it before such a mistake escapes the lab. This retroactively forbids any short option name (which is defined to be of type "int") outside the ASCII printable range. We might want to do one of two things: - tighten the type of short_name member to 'char', and further update optbug() to protect it against doing "'%c'" on a funny value, e.g. negative or above 127. - drop the check (even the "duplicate" check) for an option whose short_name is either negative or above 255, to allow clever folks to take advantage of the fact that such a short_name cannot be parsed from the command line and the member can be used to store some extra information. Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | refactor skip_prefix to return a booleanJeff King2014-06-20
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The skip_prefix() function returns a pointer to the content past the prefix, or NULL if the prefix was not found. While this is nice and simple, in practice it makes it hard to use for two reasons: 1. When you want to conditionally skip or keep the string as-is, you have to introduce a temporary variable. For example: tmp = skip_prefix(buf, "foo"); if (tmp) buf = tmp; 2. It is verbose to check the outcome in a conditional, as you need extra parentheses to silence compiler warnings. For example: if ((cp = skip_prefix(buf, "foo")) /* do something with cp */ Both of these make it harder to use for long if-chains, and we tend to use starts_with() instead. However, the first line of "do something" is often to then skip forward in buf past the prefix, either using a magic constant or with an extra strlen(3) (which is generally computed at compile time, but means we are repeating ourselves). This patch refactors skip_prefix() to return a simple boolean, and to provide the pointer value as an out-parameter. If the prefix is not found, the out-parameter is untouched. This lets you write: if (skip_prefix(arg, "foo ", &arg)) do_foo(arg); else if (skip_prefix(arg, "bar ", &arg)) do_bar(arg); Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mr/opt-set-ptr'Junio C Hamano2014-04-08
|\ | | | | | | | | | | | | | | | | | | OPT_SET_PTR() implementation was broken on IL32P64 platforms; it turns out that the macro is not used by any real user. * mr/opt-set-ptr: parse-options: remove unused OPT_SET_PTR parse-options: add cast to correct pointer type to OPT_SET_PTR MSVC: fix t0040-parse-options crash
| * parse-options: remove unused OPT_SET_PTRMarat Radchenko2014-03-31
| | | | | | | | | | | | | | OPT_SET_PTR was never used since its creation at db7244bd (parse-options new features., 2007-11-07). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | parse-options: make sure argh string does not have SP or _Junio C Hamano2014-03-24
| | | | | | | | | | | | | | | | | | | | We encourage to spell an argument hint that consists of multiple words as a single-token separated with dashes. In order to help catching violations added by new callers of parse-options, make sure argh does not contain SP or _ when the code validates the option definitions. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | use strchrnul() in place of strchr() and strlen()Rohit Mani2014-03-10
|/ | | | | | | | | Avoid scanning strings twice, once with strchr() and then with strlen(), by using strchrnul(). Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rohit Mani <rohit.mani@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* replace {pre,suf}fixcmp() with {starts,ends}_with()Christian Couder2013-12-05
| | | | | | | | | | | | | | | | | | | | | | | Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: add OPT_CMDMODE()Junio C Hamano2013-07-30
| | | | | | | | This can be used to define a set of mutually exclusive "command mode" options, and automatically catch use of more than one from that set as an error. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ef/non-ascii-parse-options-error-diag'Junio C Hamano2013-02-14
|\ | | | | | | | | * ef/non-ascii-parse-options-error-diag: parse-options: report uncorrupted multi-byte options
| * parse-options: report uncorrupted multi-byte optionsErik Faye-Lund2013-02-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because our command-line parser considers only one byte at the time for short-options, we incorrectly report only the first byte when multi-byte input was provided. This makes user-errors slightly awkward to diagnose for instance under UTF-8 locale and non-English keyboard layouts. Report the whole argument-string when a non-ASCII short-option is detected. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Improved-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jx/utf8-printf-width'Junio C Hamano2013-02-14
|\ \ | | | | | | | | | | | | | | | | | | | | | Use a new helper that prints a message and counts its display width to align the help messages parse-options produces. * jx/utf8-printf-width: Add utf8_fprintf helper that returns correct number of columns
| * | Add utf8_fprintf helper that returns correct number of columnsJiang Xin2013-02-11
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since command usages can be translated, they may include utf-8 encoded strings, and the output in console may not align well any more. This is because strlen() is different from strwidth() on utf-8 strings. A wrapper utf8_fprintf() can help to return the correct number of columns required. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | silence some -Wuninitialized false positivesJeff King2012-12-15
|/ | | | | | | | | | | | | | | | | | | | There are a few error functions that simply wrap error() and provide a standardized message text. Like error(), they always return -1; knowing that can help the compiler silence some false positive -Wuninitialized warnings. One strategy would be to just declare these as inline in the header file so that the compiler can see that they always return -1. However, gcc does not always inline them (e.g., it will not inline opterror, even with -O3), which renders our change pointless. Instead, let's follow the same route we did with error() in the last patch, and define a macro that makes the constant return value obvious to the compiler. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git on Mac OS and precomposed unicodeTorsten Bögershausen2012-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mac OS X mangles file names containing unicode on file systems HFS+, VFAT or SAMBA. When a file using unicode code points outside ASCII is created on a HFS+ drive, the file name is converted into decomposed unicode and written to disk. No conversion is done if the file name is already decomposed unicode. Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same result as open("\x41\xcc\x88",...) with a decomposed "Ä". As a consequence, readdir() returns the file names in decomposed unicode, even if the user expects precomposed unicode. Unlike on HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in precomposed unicode, but readdir() still returns file names in decomposed unicode. When a git repository is stored on a network share using SAMBA, file names are send over the wire and written to disk on the remote system in precomposed unicode, but Mac OS X readdir() returns decomposed unicode to be compatible with its behaviour on HFS+ and VFAT. The unicode decomposition causes many problems: - The names "git add" and other commands get from the end user may often be precomposed form (the decomposed form is not easily input from the keyboard), but when the commands read from the filesystem to see what it is going to update the index with already is on the filesystem, readdir() will give decomposed form, which is different. - Similarly "git log", "git mv" and all other commands that need to compare pathnames found on the command line (often but not always precomposed form; a command line input resulting from globbing may be in decomposed) with pathnames found in the tree objects (should be precomposed form to be compatible with other systems and for consistency in general). - The same for names stored in the index, which should be precomposed, that may need to be compared with the names read from readdir(). NFS mounted from Linux is fully transparent and does not suffer from the above. As Mac OS X treats precomposed and decomposed file names as equal, we can - wrap readdir() on Mac OS X to return the precomposed form, and - normalize decomposed form given from the command line also to the precomposed form, to ensure that all pathnames used in Git are always in the precomposed form. This behaviour can be requested by setting "core.precomposedunicode" configuration variable to true. The code in compat/precomposed_utf8.c implements basically 4 new functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(), precomposed_utf8_closedir() and precompose_argv(). The first three are to wrap opendir(3), readdir(3), and closedir(3) functions. The argv[] conversion allows to use the TAB filename completion done by the shell on command line. It tolerates other tools which use readdir() to feed decomposed file names into git. When creating a new git repository with "git init" or "git clone", "core.precomposedunicode" will be set "false". The user needs to activate this feature manually. She typically sets core.precomposedunicode to "true" on HFS and VFAT, or file systems mounted via SAMBA. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* i18n: parseopt: lookup help and argument translations when showing usageNguyễn Thái Ngọc Duy2012-05-08
| | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: typo check for unknown switchesRené Scharfe2012-03-04
| | | | | | | | | | | | | | | The user specifies a long option but forgets to type the second leading dash, we currently detect and report that fact if its first letter is a valid short option. This is done for safety, to avoid ambiguity between short options (and their arguments) and a long option with a missing dash. This diagnostic message is also helpful for long options whose first letter is not a valid short option, however. Print it in that case, too, as a courtesy. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: remove PARSE_OPT_NEGHELPRené Scharfe2012-02-28
| | | | | | | | | | | | PARSE_OPT_NEGHELP is confusing because short options defined with that flag do the opposite of what the helptext says. It is also not needed anymore now that options starting with no- can be negated by removing that prefix. Convert its only two users to OPT_NEGBIT() and OPT_BOOL() and then remove support for PARSE_OPT_NEGHELP. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: allow positivation of options starting, with no-René Scharfe2012-02-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Long options can be negated by adding no- right after the leading two dashes. This is useful e.g. to override options set by aliases. For options that are defined to start with no- already, this looks a bit funny. Allow such options to also be negated by removing the prefix. The following thirteen options are affected: apply --no-add bisect--helper --no-checkout checkout-index --no-create clone --no-checkout --no-hardlinks commit --no-verify --no-post-rewrite format-patch --no-binary hash-object --no-filters read-tree --no-sparse-checkout revert --no-commit show-branch --no-name update-ref --no-deref The following five are NOT affected because they are defined with PARSE_OPT_NONEG or the non-negated version is defined as well: branch --no-merged format-patch --no-stat --no-numbered update-index --no-assume-unchanged --no-skip-worktree Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: deprecate OPT_BOOLEANJunio C Hamano2011-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is natural to expect that an option defined with OPT_BOOLEAN() could be used in this way: int option = -1; /* unspecified */ struct option options[] = { OPT_BOOLEAN(0, "option", &option, "set option"), OPT_END() }; parse_options(ac, av, prefix, options, usage, 0); if (option < 0) ... do the default thing ... else if (!option) ... --no-option was given ... else ... --option was given ... to easily tell three cases apart: - There is no mention of the `--option` on the command line; - The variable is positively set with `--option`; or - The variable is explicitly negated with `--no-option`. Unfortunately, this is not the case. OPT_BOOLEAN() increments the variable every time `--option` is given, and resets it to zero when `--no-option` is given. As a first step to remedy this, introduce a true boolean OPT_BOOL(), and rename OPT_BOOLEAN() to OPT_COUNTUP(). To help transitioning, OPT_BOOLEAN and OPTION_BOOLEAN are defined as deprecated synonyms to OPT_COUNTUP and OPTION_COUNTUP respectively. This is what db7244b (parse-options new features., 2007-11-07) from four years ago started by marking OPTION_BOOLEAN as "INCR would have been a better name". Some existing users do depend on the count-up semantics; for example, users of OPT__VERBOSE() could use it to raise the verbosity level with repeated use of `-v` on the command line, but they probably should be rewritten to use OPT__VERBOSITY() instead these days. I suspect that some users of OPT__FORCE() may also use it to implement different level of forcibleness but I didn't check. On top of this patch, here are the remaining clean-up tasks that other people can help: - Look at each hit in "git grep -e OPT_BOOLEAN"; trace all uses of the value that is set to the underlying variable, and if it can proven that the variable is only used as a boolean, replace it with OPT_BOOL(). If the caller does depend on the count-up semantics, replace it with OPT_COUNTUP() instead. - Same for OPTION_BOOLEAN; replace it with OPTION_SET_INT and arrange to set 1 to the variable for a true boolean, and otherwise replace it with OPTION_COUNTUP. - Look at each hit in "git grep -e OPT__VERBOSE -e OPT__QUIET" and see if they can be replaced with OPT__VERBOSITY(). I'll follow this message up with a separate patch as an example. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Reduce parse-options.o dependenciesDmitry Ivankov2011-08-11
| | | | | | | | | | | | | | | | | | | | Currently parse-options.o pulls quite a big bunch of dependencies. his complicates it's usage in contrib/ because it pulls external dependencies and it also increases executables size. Split off less generic and more internal to git part of parse-options.c to parse-options-cb.c. Move prefix_filename function from setup.c to abspath.c. abspath.o and wrapper.o pull each other, so it's unlikely to increase the dependencies. It was a dependency of parse-options.o that pulled many others. Now parse-options.o pulls just abspath.o, ctype.o, strbuf.o, usage.o, wrapper.o, libc directly and strlcpy.o indirectly. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: export opterr, optbugDmitry Ivankov2011-08-11
| | | | | | | | | | | opterror and optbug functions are used by some of parsing routines in parse-options.c to report errors and bugs respectively. Export these functions to allow more custom parsing routines to use them in a uniform way. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: add OPT_STRING_LIST helperJeff King2011-06-22
| | | | | | | | | This just adds repeated invocations of an option to a list of strings. Using the "--no-<var>" form will reset the list to empty. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix sparse warningsStephen Boyd2011-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix warnings from 'make check'. - These files don't include 'builtin.h' causing sparse to complain that cmd_* isn't declared: builtin/clone.c:364, builtin/fetch-pack.c:797, builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78, builtin/merge-index.c:69, builtin/merge-recursive.c:22 builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426 builtin/notes.c:822, builtin/pack-redundant.c:596, builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149, builtin/remote.c:1512, builtin/remote-ext.c:240, builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384, builtin/unpack-file.c:25, builtin/var.c:75 - These files have symbols which should be marked static since they're only file scope: submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13, submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79, unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123, url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48 - These files redeclare symbols to be different types: builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571, usage.c:49, usage.c:58, usage.c:63, usage.c:72 - These files use a literal integer 0 when they really should use a NULL pointer: daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362 While we're in the area, clean up some unused #includes in builtin files (mostly exec_cmd.h). Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: make resuming easier after PARSE_OPT_STOP_AT_NON_OPTIONJonathan Nieder2010-12-07
| | | | | | | | | Introduce a PARSE_OPT_NON_OPTION state, so parse_option_step() callers can easily distinguish between non-options and other reasons for option parsing termination (like "--"). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: allow git commands to invent new option typesJonathan Nieder2010-12-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parse-options provides a variety of option behaviors, including OPTION_CALLBACK, which should take care of just about any sane behavior. All supported behaviors obey the following constraint: A --foo option can only accept (and base its behavior on) one argument, which would be the following command-line argument in the "unsticked" form. Alas, some existing git commands have options that do not obey that constraint. For example, update-index --cacheinfo takes three arguments, and update-index --resolve takes all later parameters as arguments. Introduces an OPTION_LOWLEVEL_CALLBACK backdoor to parse-options so such option types can be supported without tempting inventors of other commands through mention in the public API. Commands can set the callback field to a function accepting three arguments: the option parsing context, the option itself, and a flag indicating whether the the option was negated. When the option is encountered, that function is called to take over from get_value(). The return value should be zero for success, -1 for usage errors. Thanks to Stephen Boyd for API guidance. Improved-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: never suppress arghelp if LITERAL_ARGHELP is setJonathan Nieder2010-12-07
| | | | | | | | | | | | | | | | | | | | | The PARSE_OPT_LITERAL_ARGHELP flag allows a program to override the standard "<argument> for mandatory, [argument] for optional" markup in its help message. Extend it to override the usual "no text for disallowed", too (for the PARSE_OPT_NOARG | PARSE_OPT_LITERAL_ARGHELP case, which was previously meaningless), to be more intuitive. The motivation is to allow update-index to correctly advertise --cacheinfo <mode> <object> <path> add the specified entry to the index while abusing PARSE_OPT_NOARG to disallow the "sticked form" --cacheinfo=<mode> <object> <path> Noticed-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: do not infer PARSE_OPT_NOARG from option typeStephen Boyd2010-12-07
| | | | | | | | | | | | | | | | | | | | Simplify the "takes no value" error path by relying on PARSE_OPT_NOARG being set correctly. That is: - if the PARSE_OPT_NOARG flag is set, reject --opt=value regardless of the option type; - if the PARSE_OPT_NOARG flag is unset, accept --opt=value regardless of the option type. This way, the accepted usage more closely matches the usage advertised with --help-all. No functional change intended, since the NOARG flag is only used with "boolean-only" option types in existing parse_options callers. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: sanity check PARSE_OPT_NOARG flagJonathan Nieder2010-12-07
| | | | | | | | | | | | | | | | | Some option types cannot use an argument --- boolean options that would set a bit or flag or increment a counter, for example. If configured in the flag word to accept an argument anyway, the result is an argument that is advertised in "program -h" output only to be rejected by parse-options::get_value. Luckily all current users of these option types use PARSE_OPT_NOARG and do not use PARSE_OPT_OPTARG. Add a check to ensure that that remains true. The check is run once for each invocation of parse_option_start(). Improved-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: move NODASH sanity checks to parse_options_checkJonathan Nieder2010-12-07
| | | | | | | | | | | | | | | | | | | | | A dashless switch (like '(' passed to 'git grep') cannot be negated, cannot be attached to an argument, and cannot have a long form. Currently parse-options runs the related sanity checks when the dashless option is used; better to always check them at the start of option parsing, so mistakes can be caught more quickly. The error message at the new call site is less specific about the nature of the error, for simplicity. On the other hand, it prints which switch was problematic. Before: fatal: BUG: dashless options can't be long After: error: BUG: switch '(' uses feature not supported for dashless options Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: clearer reporting of API misuseJonathan Nieder2010-12-07
| | | | | | | | | | | | | | | | | | | | | | | | | | The PARSE_OPT_LASTARG_DEFAULT flag is meant for options like --contains that (1) traditionally had a mandatory argument and (2) have some better behavior to use when appearing in the final position. It makes no sense to combine this with OPTARG, so ever since v1.6.4-rc0~71 (parse-options: add parse_options_check to validate option specs, 2009-07-09) this mistake is flagged with error: `--option` uses incompatible flags LASTARG_DEFAULT and OPTARG and an exit status representing an error in commandline usage. Unfortunately that which might confuse scripters calling such an erroneous program into thinking the _script_ contains an error. Clarify that it is an internal error by dying with a message beginning "error: BUG: ..." and status 128. While at it, clean up parse_options_check to prepare for more checks. Long term, it would be nicer to make such checks happen at compile time. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: Don't call parse_options_check() so muchStephen Boyd2010-12-06
| | | | | | | | | | | | | parse_options_check() is being called for each invocation of parse_options_step which can be quite a bit for some commands. The commit introducing this function cb9d398 (parse-options: add parse_options_check to validate option specs., 2009-06-09) had the correct motivation and explicitly states that parse_options_check() should be called from parse_options_start(). However, the implementation differs from the motivation. Fix it. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parseopt: wrap rev-parse --parseopt usage for eval consumptionThomas Rast2010-06-13
| | | | | | | | | | | | | 9c7304e (print the usage string on stdout instead of stderr, 2010-05-17) broke rev-parse --parseopt: when run with -h, the usage notice on stdout ended up in the shell eval. Wrap the usage in a cat <<\EOF ... EOF block when printing to stdout. I do not expect any usage lines to ever start with EOF so this shouldn't be an undue burden. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* print the usage string on stdout instead of stderrGiuseppe Scrivano2010-05-31
| | | | | | | | When -h is used, print usage messages on stdout. If a command is invoked with wrong arguments then print the usage messages on stderr. Signed-off-by: Giuseppe Scrivano <gscrivano@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-options: add parse_options_concat() to concat optionsJunio C Hamano2010-03-06
| | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add an optional argument for --color optionsMark Lodato2010-02-18
| | | | | | | | | | | | | | | | | | | | | | | | Make git-branch, git-show-branch, git-grep, and all the diff-based programs accept an optional argument <when> for --color. The argument is a colorbool: "always", "never", or "auto". If no argument is given, "always" is used; --no-color is an alias for --color=never. This makes the command-line interface consistent with other GNU tools, such as `ls' and `grep', and with the git-config color options. Note that, without an argument, --color and --no-color work exactly as before. To implement this, two internal changes were made: 1. Allow the first argument of git_config_colorbool() to be NULL, in which case it returns -1 if the argument isn't "always", "never", or "auto". 2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb() to the option parsing library. The callback uses git_config_colorbool(), so color.h is now a dependency of parse-options.c. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/symbol-static'Junio C Hamano2010-01-20
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/symbol-static: date.c: mark file-local function static Replace parse_blob() with an explanatory comment symlinks.c: remove unused functions object.c: remove unused functions strbuf.c: remove unused function sha1_file.c: remove unused function mailmap.c: remove unused function utf8.c: mark file-local function static submodule.c: mark file-local function static quote.c: mark file-local function static remote-curl.c: mark file-local function static read-cache.c: mark file-local functions static parse-options.c: mark file-local function static entry.c: mark file-local function static http.c: mark file-local functions static pretty.c: mark file-local function static builtin-rev-list.c: mark file-local function static bisect.c: mark file-local function static
| * parse-options.c: mark file-local function staticJunio C Hamano2010-01-12
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Teach --[no-]rerere-autoupdate option to merge, revert and friendsJunio C Hamano2009-12-04
|/ | | | | | | Introduce a command line option to override rerere.autoupdate configuration variable to make it more useful. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-opt: ignore negation of OPT_NONEG for ambiguity checksAndreas Schwab2009-09-29
| | | | | | | | | | | | | | | | parse_long_opt always matches both --opt and --no-opt for any option "opt", and only get_value checks whether --no-opt is actually valid. Since the options for git branch contains both "no-merged" and "merged" there are two matches for --no-merge, but no exact match. With this patch the negation of a NONEG option is rejected earlier, but it changes the error message from "option `no-opt' isn't available" to "unknown option `no-opt'". [jk: added test] Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Merge branch 'cc/replace'Junio C Hamano2009-08-21
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * cc/replace: t6050: check pushing something based on a replaced commit Documentation: add documentation for "git replace" Add git-replace to .gitignore builtin-replace: use "usage_msg_opt" to give better error messages parse-options: add new function "usage_msg_opt" builtin-replace: teach "git replace" to actually replace Add new "git replace" command environment: add global variable to disable replacement mktag: call "check_sha1_signature" with the replacement sha1 replace_object: add a test case object: call "check_sha1_signature" with the replacement sha1 sha1_file: add a "read_sha1_file_repl" function replace_object: add mechanism to replace objects found in "refs/replace/" refs: add a "for_each_replace_ref" function
| * parse-options: add new function "usage_msg_opt"Christian Couder2009-05-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function can be used instead of "usage_with_options" when you want to print an error message before the usage string. It may be useful because: if (condition) usage_msg_opt("condition is false", usage, opts); is shorter than: if (condition) { fprintf(stderr, "condition is false\n\n"); usage_with_options(usage, opts); } and may be more consistent. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | parse-opt: optionally show "--no-" option stringJohannes Schindelin2009-07-31
| | | | | | | | | | | | | | | | | | | | | | It is usually better to have positive options, to avoid confusing double negations. However, sometimes it is desirable to show the negative option in the help. Introduce the flag PARSE_OPT_NEGHELP to do that. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Fix various sparse warnings in the git source codeLinus Torvalds2009-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few remaining ones, but this fixes the trivial ones. It boils down to two main issues that sparse complains about: - warning: Using plain integer as NULL pointer Sparse doesn't like you using '0' instead of 'NULL'. For various good reasons, not the least of which is just the visual confusion. A NULL pointer is not an integer, and that whole "0 works as NULL" is a historical accident and not very pretty. A few of these remain: zlib is a total mess, and Z_NULL is just a 0. I didn't touch those. - warning: symbol 'xyz' was not declared. Should it be static? Sparse wants to see declarations for any functions you export. A lack of a declaration tends to mean that you should either add one, or you should mark the function 'static' to show that it's in file scope. A few of these remain: I only did the ones that should obviously just be made static. That 'wt_status_submodule_summary' one is debatable. It has a few related flags (like 'wt_status_use_color') which _are_ declared, and are used by builtin-commit.c. So maybe we'd like to export it at some point, but it's not declared now, and not used outside of that file, so 'static' it is in this patch. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-26 04:24:47 +0000