- 23 6月, 2015 1 次提交
-
-
由 Charles Bailey 提交于
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: NCharles Bailey <cbailey32@bloomberg.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 9月, 2014 1 次提交
-
-
由 Junio C Hamano 提交于
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: NRené Scharfe <l.s.r@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 6月, 2014 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 4月, 2014 1 次提交
-
-
由 Marat Radchenko 提交于
OPT_SET_PTR was never used since its creation at db7244bd (parse-options new features., 2007-11-07). Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 3月, 2014 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 10 3月, 2014 1 次提交
-
-
由 Rohit Mani 提交于
Avoid scanning strings twice, once with strchr() and then with strlen(), by using strchrnul(). Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NRohit Mani <rohit.mani@outlook.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 12月, 2013 1 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 7月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 12 2月, 2013 2 次提交
-
-
由 Erik Faye-Lund 提交于
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: NErik Faye-Lund <kusmabite@gmail.com> Improved-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jiang Xin 提交于
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: NJiang Xin <worldhello.net@gmail.com> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 12月, 2012 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 7月, 2012 1 次提交
-
-
由 Torsten Bögershausen 提交于
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: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 5月, 2012 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 3月, 2012 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 2月, 2012 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Acked-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 2月, 2012 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 9月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
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 db7244bd (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: NJunio C Hamano <gitster@pobox.com>
-
- 19 8月, 2011 1 次提交
-
-
由 Jeff King 提交于
Usually this function figures out for itself whether stdout is a tty. However, it has an extra parameter just to allow git-config to override the auto-detection for its --get-colorbool option. Instead of an extra parameter, let's just use a global variable. This makes calling easier in the common case, and will make refactoring the colorbool code much simpler. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2011 2 次提交
-
-
由 Dmitry Ivankov 提交于
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: NDmitry Ivankov <divanorama@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Dmitry Ivankov 提交于
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: NDmitry Ivankov <divanorama@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 6月, 2011 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 3月, 2011 1 次提交
-
-
由 Stephen Boyd 提交于
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: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 12月, 2010 7 次提交
-
-
由 Jonathan Nieder 提交于
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: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
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: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
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: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephen Boyd 提交于
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: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
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: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
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: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
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: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 12月, 2010 1 次提交
-
-
由 Stephen Boyd 提交于
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 cb9d398c (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: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 6月, 2010 1 次提交
-
-
由 Thomas Rast 提交于
9c7304e3 (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: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 6月, 2010 1 次提交
-
-
由 Giuseppe Scrivano 提交于
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: NGiuseppe Scrivano <gscrivano@gnu.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 3月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 2月, 2010 1 次提交
-
-
由 Mark Lodato 提交于
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: NMark Lodato <lodatom@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 1月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 12月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
Introduce a command line option to override rerere.autoupdate configuration variable to make it more useful. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 9月, 2009 1 次提交
-
-
由 Andreas Schwab 提交于
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: NAndreas Schwab <schwab@linux-m68k.org> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 31 7月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 6月, 2009 1 次提交
-
-
由 Pierre Habouzit 提交于
It only searches for now for the dreaded LASTARG_DEFAULT | OPTARG combination, but can be extended to check for any other forbidden combination. Options are checked each time we call parse_options_start. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-