git/parse-options.h, branch v2.18.2

Merge branch 'ps/contains-id-error-message'

2018-04-10T07:28:20Z

"git tag --contains no-such-commit" gave a full list of options after giving an error message. * ps/contains-id-error-message: parse-options: do not show usage upon invalid option value

parse-options: do not show usage upon invalid option value

2018-03-22T19:10:08Z

Usually, the usage should be shown only if the user does not know what options are available. If the user specifies an invalid value, the user is already aware of the available options. In this case, there is no point in displaying the usage anymore. This patch applies to "git tag --contains", "git branch --contains", "git branch --points-at", "git for-each-ref --contains" and many more. Signed-off-by: Paul-Sebastian Ungureanu Signed-off-by: Junio C Hamano

completion: don't set PARSE_OPT_NOCOMPLETE on --rerere-autoupdate

2018-03-07T19:02:48Z

There is not a strong reason to hide this option, and git-merge already completes this one. Let's allow to complete this for all commands (and let git-completion.bash do the suppressing if needed). This makes --rerere-autoupdate completable for am, cherry-pick and revert. rebase completion is fixed manually because it's a shell script and does not benefit from --git-completion-helper. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

remote: force completing --mirror= instead of --mirror

2018-02-09T18:24:52Z

"git remote --mirror" is a special case. Technically it is possible to specify --mirror without any argument. But we will get a "dangerous, deprecated!" warning in that case. This new parse-opt flag allows --git-completion-helper to always complete --mirror=, ignoring the dangerous use case. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

completion: use __gitcomp_builtin in _git_am

2018-02-09T18:24:50Z

The new completable options are: --directory --exclude --gpg-sign --include --keep-cr --keep-non-patch --message-id --no-keep-cr --patch-format --quiet --reject --resolvemsg= In-progress options like --continue will be part of --git-completion-helper then filtered out by _git_am() unless the operation is in progress. This helps keep marking of these operations in just one place. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

parse-options: let OPT__FORCE take optional flags argument

2018-02-09T18:24:50Z

--force option is most likely hidden from command line completion for safety reasons. This is done by adding an extra flag PARSE_OPT_NOCOMPLETE. Update OPT__FORCE() to accept additional flags. Actual flag change comes later depending on individual commands. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

parse-options: add OPT_xxx_F() variants

2018-02-09T18:24:50Z

These macros allow us to add extra parse-options flag, the main one in my mind is PARSE_OPT_NOCOMPLETE to hide certain options from --git-completion-helper. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

parse-options: support --git-completion-helper

2018-02-09T18:24:49Z

This option is designed to be used by git-completion.bash. For many simple cases, what we do in there is usually __gitcomp "lots of completion options" which has to be manually updated when a new user-visible option is added. With support from parse-options, we can write __gitcomp "$(git command --git-completion-helper)" and get that list directly from the parser for free. Dangerous/Unpopular options could be hidden with the new "NOCOMPLETE" flag. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

ref-filter: add --no-contains option to tag/branch/for-each-ref

2017-03-24T19:15:26Z

Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad . Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options: add OPT_NONEG to the "contains" option

2017-03-24T19:15:25Z

Add the OPT_NONEG flag to the "contains" option and its hidden synonym "with". Since this was added in commit 694a577519 ("git-branch --contains=commit", 2007-11-07) giving --no-{contains,with} hasn't been an error, but has emitted the help output since filter.with_commit wouldn't get set. Now git will emit "error: unknown option `no-{contains,with}'" at the top of the help output. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano