git/Documentation/technical/api-parse-options.txt, branch gitk-resize-error

parse-options API: remove OPTION_ARGUMENT feature

2021-09-13T06:27:38Z

As was noted in 1a85b49b87a (parse-options: make OPT_ARGUMENT() more useful, 2019-03-14) there's only ever been one user of the OPT_ARGUMENT(), that user was added in 20de316e334 (difftool: allow running outside Git worktrees with --no-index, 2019-03-14). The OPT_ARGUMENT() feature itself was added way back in 580d5bffdea (parse-options: new option type to treat an option-like parameter as an argument., 2008-03-02), but as discussed in 1a85b49b87a wasn't used until 20de316e334 in 2019. Now that the preceding commit has migrated this code over to using "struct strvec" to manage the "args" member of a "struct child_process", we can just use that directly instead of relying on OPT_ARGUMENT. This has a minor change in behavior in that if we'll pass --no-index we'll now always pass it as the first argument, before we'd pass it in whatever position the caller did. Preserving this was the real value of OPT_ARGUMENT(), but as it turns out we didn't need that either. We can always inject it as the first argument, the other end will parse it just the same. Note that we cannot remove the "out" and "cpidx" members of "struct parse_opt_ctx_t" added in 580d5bffdea, while they were introduced with OPT_ARGUMENT() we since used them for other things. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

strvec: update documention to avoid argv_array

2020-07-28T22:02:18Z

There were a few mentions of argv_array in a non-code file which didn't get picked up in the previous commits (note that even comments in code files were already covered because of the mechanical conversion via perl). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

parse-options: make OPT_ARGUMENT() more useful

2019-03-18T02:44:14Z

`OPT_ARGUMENT()` is intended to keep the specified long option in `argv` and not to do anything else. However, it would make a lot of sense for the caller to know whether this option was seen at all or not. For example, we want to teach `git difftool` to work outside of any Git worktree, but only when `--no-index` was specified. Note: nothing in Git uses OPT_ARGUMENT(). Even worse, looking through the commit history, one can easily see that nothing even ever used it, apart from the regression test. So not only do we make `OPT_ARGUMENT()` more useful, we are also about to introduce its first real user! Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

parse-options: drop OPT_DATE()

2018-11-06T03:56:14Z

There are no users of OPT_DATE except for test-parse-options; its only caller went away in 27ec394a97 (prune: introduce OPT_EXPIRY_DATE() and use it, 2013-04-25). It also has a bug: it does not specify PARSE_OPT_NONEG, but its callback does not respect the "unset" flag, and will feed NULL to approxidate() and segfault. Probably this should be marked with NONEG, or the callback should set the timestamp to some sentinel value (e.g,. "0", or "(time_t)-1"). But since there are no callers, deleting it means we don't even have to think about what the right behavior should be. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

timestamp_t: a new data type for timestamps

2017-04-27T04:07:39Z

Git's source code assumes that unsigned long is at least as precise as time_t. Which is incorrect, and causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions). So let's just use a more appropriate data type instead. In preparation for this, we introduce the new `timestamp_t` data type. By necessity, this is a very, very large patch, as it has to replace all timestamps' data type in one go. As we will use a data type that is not necessarily identical to `time_t`, we need to be very careful to use `time_t` whenever we interact with the system functions, and `timestamp_t` everywhere else. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

doc: add documentation for OPT_STRING_LIST

2017-01-19T21:10:09Z

Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper", 2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated list of strings. However, this was not documented in the api-parse-options documentation. Add documentation now so that future developers may learn of its existence. Signed-off-by: Jacob Keller Signed-off-by: Junio C Hamano

parse-options.c: make OPTION_COUNTUP respect "unspecified" values

2016-05-05T18:52:45Z

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 Helped-by: Eric Sunshine Helped-by: Junio C Hamano Signed-off-by: Pranit Bauva Signed-off-by: Junio C Hamano

api-parse-options.txt: document OPT_CMDMODE()

2016-03-25T20:17:43Z

OPT_CMDMODE mechanism was introduced in the release of 1.8.5 to actively notice when multiple "operation mode" options that specify mutually incompatible operation modes are given. Signed-off-by: Pranit Bauva Signed-off-by: Junio C Hamano

Merge branch 'pt/pull-builtin'

2015-08-03T18:01:17Z

Reimplement 'git pull' in C. * pt/pull-builtin: pull: remove redirection to git-pull.sh pull --rebase: error on no merge candidate cases pull --rebase: exit early when the working directory is dirty pull: configure --rebase via branch..rebase or pull.rebase pull: teach git pull about --rebase pull: set reflog message pull: implement pulling into an unborn branch pull: fast-forward working tree if head is updated pull: check if in unresolved merge state pull: support pull.ff config pull: error on no merge candidates pull: pass git-fetch's options to git-fetch pull: pass git-merge's options to git-merge pull: pass verbosity, --progress flags to fetch and merge pull: implement fetch + merge pull: implement skeletal builtin pull argv-array: implement argv_array_pushv() parse-options-cb: implement parse_opt_passthru_argv() parse-options-cb: implement parse_opt_passthru()

parse-options: move unsigned long option parsing out of pack-objects.c

2015-06-22T22:07:21Z

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 Signed-off-by: Junio C Hamano