summaryrefslogtreecommitdiff
path: root/t/t9902-completion.sh
AgeCommit message (Collapse)Author
2021-09-03Merge branch 'fc/completion-updates'Junio C Hamano
Command line completion updates. * fc/completion-updates: completion: bash: add correct suffix in variables completion: bash: fix for multiple dash commands completion: bash: fix for suboptions with value completion: bash: fix prefix detection in branch.*
2021-08-18completion: bash: fix for suboptions with valueFelipe Contreras
We need to ignore options that don't start with -- as well. Depending on the value of COMP_WORDBREAKS the last word could be duplicated otherwise. Can be tested with: git merge -X diff-algorithm=<tab> Tested-by: David Aguilar <davvid@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-16parse-options: don't complete option aliases by defaultPhilippe Blain
Since 'OPT_ALIAS' was created in 5c387428f1 (parse-options: don't emit "ambiguous option" for aliases, 2019-04-29), 'git clone --git-completion-helper', which is used by the Bash completion script to list options accepted by clone (via '__gitcomp_builtin'), lists both '--recurse-submodules' and its alias '--recursive', which was not the case before since '--recursive' had the PARSE_OPT_HIDDEN flag set, and options with this flag are skipped by 'parse-options.c::show_gitcomp', which implements 'git <cmd> --git-completion-helper'. This means that typing 'git clone --recurs<TAB>' will yield both '--recurse-submodules' and '--recursive', which is not ideal since both do the same thing, and so the completion should directly complete the canonical option. At the point where 'show_gitcomp' is called in 'parse_options_step', 'preprocess_options' was already called in 'parse_options', so any aliases are now copies of the original options with a modified help text indicating they are aliases. Helpfully, since 64cc539fd2 (parse-options: don't leak alias help messages, 2021-03-21) these copies have the PARSE_OPT_FROM_ALIAS flag set, so check that flag early in 'show_gitcomp' and do not print them, unless the user explicitely requested that *all* completion be shown (by setting 'GIT_COMPLETION_SHOW_ALL'). After all, if we want to encourage the use of '--recurse-submodules' over '--recursive', we'd better just suggest the former. The only other options alias is 'log' and friends' '--mailmap', which is an alias for '--use-mailmap', but the Bash completion helpers for these commands do not use '__gitcomp_builtin', and thus are unnaffected by this change. Test the new behaviour in t9902-completion.sh. As a side effect, this also tests the correct behaviour of GIT_COMPLETION_SHOW_ALL, which was not tested before. Note that since '__gitcomp_builtin' caches the options it shows, we need to re-source the completion script to clear that cache for the second test. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-07Merge branch 'dl/complete-stash-updates'Junio C Hamano
Further update the command line completion (in contrib/) for "git stash". * dl/complete-stash-updates: git-completion.bash: consolidate cases in _git_stash() git-completion.bash: use $__git_cmd_idx in more places git-completion.bash: rename to $__git_cmd_idx git-completion.bash: separate some commands onto their own line
2021-04-27git-completion.bash: use $__git_cmd_idx in more placesDenton Liu
With the introduction of the $__git_cmd_idx variable in e94fb44042 (git-completion.bash: pass $__git_subcommand_idx from __git_main(), 2021-03-24), completion functions were able to know the index at which the git command is listed, allowing them to skip options that are given to the underlying git itself, not the corresponding command (e.g. `-C asdf` in `git -C asdf branch`). While most of the changes here are self-explanatory, some bear further explanation. For the __git_find_on_cmdline() and __git_find_last_on_cmdline() pair of functions, these functions are only ever called in the context of a git command completion function. These functions will only care about words after the command so we can safely ignore the words before this. For _git_worktree(), this change is technically a no-op (once the __git_find_last_on_cmdline change is also applied). It was in poor style to have hard-coded on the index right after `worktree`. In case `git worktree` were to ever learn to accept options, the current situation would be inflexible. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-17diff-merges: introduce log.diffMerges config variableSergey Organov
New log.diffMerges configuration variable sets the format that --diff-merges=on will be using. The default is "separate". t4013: add the following tests for log.diffMerges config: * Test that wrong values are denied. * Test that the value of log.diffMerges properly affects both --diff-merges=on and -m. t9902: fix completion tests for log.d* to match log.diffMerges. Added documentation for log.diffMerges. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-10Merge branch 'ab/detox-gettext-tests'Junio C Hamano
Get rid of "GETTEXT_POISON" support altogether, which may or may not be controversial. * ab/detox-gettext-tests: tests: remove uses of GIT_TEST_GETTEXT_POISON=false tests: remove support for GIT_TEST_GETTEXT_POISON ci: remove GETTEXT_POISON jobs
2021-01-25Merge branch 'js/default-branch-name-tests-final-stretch'Junio C Hamano
Prepare tests not to be affected by the name of the default branch "git init" creates. * js/default-branch-name-tests-final-stretch: (28 commits) tests: drop prereq `PREPARE_FOR_MAIN_BRANCH` where no longer needed t99*: adjust the references to the default branch name "main" tests(git-p4): transition to the default branch name `main` t9[5-7]*: adjust the references to the default branch name "main" t9[0-4]*: adjust the references to the default branch name "main" t8*: adjust the references to the default branch name "main" t7[5-9]*: adjust the references to the default branch name "main" t7[0-4]*: adjust the references to the default branch name "main" t6[4-9]*: adjust the references to the default branch name "main" t64*: preemptively adjust alignment to prepare for `master` -> `main` t6[0-3]*: adjust the references to the default branch name "main" t5[6-9]*: adjust the references to the default branch name "main" t55[4-9]*: adjust the references to the default branch name "main" t55[23]*: adjust the references to the default branch name "main" t551*: adjust the references to the default branch name "main" t550*: adjust the references to the default branch name "main" t5503: prepare aligned comment for replacing `master` with `main` t5[0-4]*: adjust the references to the default branch name "main" t5323: prepare centered comment for `master` -> `main` t4*: adjust the references to the default branch name "main" ...
2021-01-21tests: remove uses of GIT_TEST_GETTEXT_POISON=falseÆvar Arnfjörð Bjarmason
As noted in previous commits we are removing the use of GIT_TEST_GETTEXT_POISON=false. These tests all relied on the facility being off, it always is off after an earlier change, but we hadn't removed the redundant assignments to "false" in the tests. I'm preserving the deletion of "error" lines in 38b9197a76a (t5411: add basic test cases for proc-receive hook, 2020-08-27), it turns out that's useful even without GIT_TEST_GETTEXT_POISON=true in play. Update a comment added in that commit to note that. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04completion: add proper public __git_completeFelipe Contreras
When __git_complete was introduced, it was meant to be temporarily, while a proper guideline for public shell functions was established (tentatively _GIT_complete), but since that never happened, people in the wild started to use __git_complete, even though it was marked as not public. Eight years is more than enough wait, let's mark this function as public, and make it a bit more user-friendly. So that instead of doing: __git_complete gk __gitk_main The user can do: __git_complete gk gitk And instead of: __git_complete gf _git_fetch Do: __git_complete gf git_fetch Backwards compatibility is maintained. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04test: completion: add tests for __git_completeFelipe Contreras
Even though the function was marked as not public, it's already used in the wild. We should at least test basic functionality. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-17t9902: use `main` as initial branch nameJohannes Schindelin
In 8164360fc86 (t9902: prepare a test for the upcoming default branch name, 2020-10-23), we started adjusting this test script for the default initial branch name changing to `main`. However, there is no need to wait for that: let's adjust the test script to stop relying on a specific initial branch name by setting it explicitly. This allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from one test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01test: completion: fix typosFelipe Contreras
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Johannes Schindelin
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-10completion: bash: support recursive aliasesFelipe Contreras
It is possible to have recursive aliases like: l = log --oneline lg = l --graph So the completion should detect such aliases as well. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09Merge branch 'fc/zsh-completion'Junio C Hamano
Zsh autocompletion (in contrib/) update. * fc/zsh-completion: (29 commits) zsh: update copyright notices completion: bash: remove old compat wrappers completion: bash: cleanup cygwin check completion: bash: trivial cleanup completion: zsh: add simple version check completion: zsh: trivial simplification completion: zsh: add alias descriptions completion: zsh: improve command tags completion: zsh: refactor command completion completion: zsh: shuffle functions around completion: zsh: simplify file_direct completion: zsh: simplify nl_append completion: zsh: trivial cleanup completion: zsh: simplify direct compadd completion: zsh: simplify compadd functions completion: zsh: fix splitting of words completion: zsh: add missing direct_append completion: fix conflict with bashcomp completion: zsh: fix completion for --no-.. options completion: bash: remove zsh wrapper ...
2020-11-02Merge branch 'js/default-branch-name-part-4-minus-1'Junio C Hamano
Adjust tests so that they won't scream when the default initial branch name is changed to 'main'. * js/default-branch-name-part-4-minus-1: t1400: prepare for `main` being default branch name tests: prepare aligned mentions of the default branch name t9902: prepare a test for the upcoming default branch name t3200: prepare for `main` being shorter than `master` t5703: adjust a test case for the upcoming default branch name t6200: adjust suppression pattern to also match "main" tests: start moving to a different default main branch name t9801: use `--` in preparation for default branch rename fmt-merge-msg: also suppress "into main" by default
2020-10-28zsh: update copyright noticesFelipe Contreras
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-23t9902: prepare a test for the upcoming default branch nameJohannes Schindelin
We need to adjust a test that uses a prefix of the default branch name, to accommodate for `main` being used soon. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08checkout: learn to respect checkout.guessDenton Liu
The current behavior of git checkout/switch is that --guess is currently enabled by default. However, some users may not wish for this to happen automatically. Instead of forcing users to specify --no-guess manually each time, teach these commands the checkout.guess configuration variable that gives users the option to set a default behavior. Teach the completion script to recognize the new config variable and disable DWIM logic if it is set to false. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27t9902: avoid using the branch name `master`Johannes Schindelin
The completion tests used that name unnecessarily, and it is a non-inclusive term, so let's avoid using it here. Since three of the touched test cases make use of the fact that two of the branch names (`master` and `maint`) start with the same letter (or even with the same two letters), we choose to replace the use of `master` by a name that also has that property: `main`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-07Merge branch 'js/pu-to-seen'Junio C Hamano
The documentation and some tests have been adjusted for the recent renaming of "pu" branch to "seen". * js/pu-to-seen: tests: reference `seen` wherever `pu` was referenced docs: adjust the technical overview for the rename `pu` -> `seen` docs: adjust for the recent rename of `pu` to `seen`
2020-06-25Merge branch 'jk/complete-git-switch'Junio C Hamano
The command line completion (in contrib/) learned to complete options that the "git switch" command takes. * jk/complete-git-switch: completion: improve handling of --orphan option of switch/checkout completion: improve handling of -c/-C and -b/-B in switch/checkout completion: improve handling of --track in switch/checkout completion: improve handling of --detach in checkout completion: improve completion for git switch with no options completion: improve handling of DWIM mode for switch/checkout completion: perform DWIM logic directly in __git_complete_refs completion: extract function __git_dwim_remote_heads completion: replace overloaded track term for __git_complete_refs completion: add tests showing subpar switch/checkout --orphan logic completion: add tests showing subpar -c/C argument completion completion: add tests showing subpar -c/-C startpoint completion completion: add tests showing subpar switch/checkout --track logic completion: add tests showing subar checkout --detach logic completion: add tests showing subpar DWIM logic for switch/checkout completion: add test showing subpar git switch completion
2020-06-25tests: reference `seen` wherever `pu` was referencedJohannes Schindelin
As our test suite partially reflects how we work in the Git project, it is natural that the branch name `pu` was used in a couple places. Since that branch was renamed to `seen`, let's use the new name consistently. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of --orphan option of switch/checkoutJacob Keller
The --orphan option is used to create a local branch which is detached from the current history. In git switch, it always resets to the empty tree, and thus the only completion we can provide is a branch name. Follow the same rules for -c/-C (and -b/-B) when completing the argument to --orphan. In the case of git switch, after we complete the argument, there is nothing more we can complete for git switch, so do not even try. Nothing else would be valid. In the case of git checkout, --orphan takes a start point which it uses to determine the checked out tree, even though it created orphaned history. Update the previously added test cases as they are now passing. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of -c/-C and -b/-B in switch/checkoutJacob Keller
A previous commit added several test cases highlighting the subpar completion logic for -c/-C and -b/-B when completing git switch and git checkout. In order to distinguish completing the argument vs the start-point for this option, we now use the wordlist to determine the previous full word on the command line. If it's -c or -C (-b/-B for checkout), then we know that we are completing the argument for the branch name. Given that a user who already knows the branch name they want to complete will simply not use completion, it makes sense to complete the small subset of local branches when completing the argument for -c/-C. In all other cases, if -c/-C are on the command line but are not the most recent option, then we must be completing a start-point, and should allow completing against all references. Update the -c/-C and -b/-B tests to indicate they now pass. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of --track in switch/checkoutJacob Keller
Current completion for the --track option of git switch and git checkout is sub par. In addition to the DWIM logic of a bare branch name, --track has DWIM logic to convert specified remote/branch names into a local branch tracking that remote. For example $git switch --track origin/master This will create a local branch name master, that tracks the master branch of the origin remote. In fact, git switch --track on its own will not accept other forms of references. These must instead be specified manually via the -c/-C/-b/-B options. Introduce __git_remote_heads() and the "remote-heads" mode for __git_complete_refs. Use this when the --track option is provided while completing in _git_switch and _git_checkout. Just as in the --detach case, we never enable DWIM mode for --track, because it doesn't make sense. It should be noted that completion support is still a bit sub par when it comes to handling -c/-C and --orphan. This will be resolved in a future change. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of --detach in checkoutJacob Keller
Just like git switch, we should not complete DWIM remote branch names if --detach has been specified. To avoid this, refactor _git_checkout in a similar way to _git_switch. Note that we don't simply clear dwim_opt when we find -d or --detach, as we will be adding other modes and checks, making this flow easier to follow. Update the previously failing tests to show that the breakage has been resolved. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve completion for git switch with no optionsJacob Keller
Add a new --mode option to __git_complete_refs, which allows changing the behavior to call __git_heads instead of __git_refs. By passing --mode=heads, __git_complete_refs will only output local branches. This enables using "--mode=heads --dwim" to enable listing local branches and the remote unique branch names for DWIM. Refactor completion support to use the new mode option, rather than calling __git_heads directly. This has the advantage that we can now correctly allow local branches along with suitable DWIM refs, rather than only allowing DWIM when we complete all references. Choose what mode it uses when calling __git_complete_refs. If -d or --detach have been provided, then simply complete all refs, but *without* the DWIM option as these DWIM names won't work properly in --detach mode. Otherwise, call __git_complete_refs with the default dwim_opt value and use the new "heads" mode. In this way, the basic support for completing just "git switch <TAB>" will result in only local branches and remote unique names for DWIM. The basic no-options tests for git switch, as well as several of the -c/-C tests now pass, so remove the known breakage tags. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of DWIM mode for switch/checkoutJacob Keller
A new helper, __git_find_last_on_cmdline is introduced, similar to the already existing __git_find_on_cmdline, but which operates in reverse, finding the *last* matching word of the provided wordlist. Use this in a new __git_checkout_default_dwim_mode() function that will determine when to enable listing of DWIM remote branches. The __git_find_last_on_cmdline() function is used to determine which --guess or --no-guess is in effect. If either one is provided, then we unconditionally enable or disable the DWIM mode based on the last provided option. If neither --guess nor --no-guess is provided, then we check for --no-track, and finally for GIT_COMPLETION_CHECKOUT_NO_GUESS=1. This function is then used in _git_switch and _git_checkout to improve the handling for when we enable listing of these DWIM remote branches. This new logic is more robust, as we will correctly identify superseded options, and ensure that both _git_switch and _git_checkout enable DWIM in similar ways. We can now update a few tests to indicate they pass. A few of the tests previously added to highlight issues with the old DWIM logic still fail. This is because of a separate issue related to the default completion behavior of git switch, which will be addressed in a future change. Additionally, due to this change, a few tests for the -b/-B handling of git checkout now fail. This is a minor regression, and will be fixed by a following change that improves the overall handling of -b/-B. Mark these tests as known breakages for now. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: add tests showing subpar switch/checkout --orphan logicJacob Keller
Similar to -c/-C, --orphan takes an argument which is the branch name to use. We ought to complete this branch name using similar rules as to how we complete new branch names for -c/-C and -b/-B. Namely, limit the total number of options provided by completing to the local branches. Additionally, git switch --orphan does not take any start point and will always create using the empty-tree. Thus, after the branch name is completed, git switch --orphan should not complete any references. Add test cases showing the expected behavior of --orphan, for both the argument and starting point. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: add tests showing subpar -c/C argument completionJacob Keller
When using the branch creation argument for git switch or git checkout (-c/-C or -b/-B), the commands switch to a different mode: `git switch -c <branch> <some-referance>` means to create a branch named <branch> at the commit referred to by <some-reference>. When completing git switch or git checkout, it makes sense to complete the branch name differently from the start point. When completing a branch, one might consider that we do not have anything worth completing. After all, a new branch must have an entirely new name. Consider, however, that if a user names branches using some similar scheme, they might wish to name a new branch by modifying the name of an existing branch. To avoid overloading completion for the argument, it seems reasonable to complete only the local branch names and the valid "Do What I Mean" remote branch names. Add tests for the completion of the argument to -c/-C and -b/-B, highlighting this preferred completion behavior. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: add tests showing subpar -c/-C startpoint completionJacob Keller
When using the branch creation argument for git switch or git checkout, -c/-C or -b/-B, the commands operate in a different mode: `git switch -c <branch> <some-reference>` means to create a branch named <branch> at the commit referred to by <some-reference>. When completing the start-point, we ought to always complete all valid references. Add tests for the completion of the start-point to -c/-C and -b/-B. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: add tests showing subpar switch/checkout --track logicJacob Keller
When the --track option is provided to git switch or git checkout, and no branch is specified by -c or -b, git will interpret the tracking branch to determine the local branch name to use. This "Do What I Mean" logic is similar but distinct from the default DWIM logic of interpreting a unique remote branch name as a request to create and track that branch. For example, `git switch --track origin/master` is interpreted as a request to create a local branch named master that is tracking origin/master. The current completion for git checkout in this regard is only somewhat poor: $git checkout --track <TAB> HEAD master matching-branch matching-tag other/branch-in-other other/master-in-other At least it still includes remote references. The clutter from including all references isn't too bad. However, git switch completion is terrible: $git switch --track <TAB> master matching-branch It only shows local branches, not even allowing any form of completion of the remote references! Add tests which highlight the expected behavior of completing --track on its own. Note that when -c/-C or -b/-B are provided we do expect completing more references, but this will be discussed in a future change that addresses these options specifically. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: add tests showing subar checkout --detach logicJacob Keller
When completing words for git switch, the completion function correctly disables the DWIM remote branch names when in the '--detach' mode. These DWIM remote branch names will not work when the --detach option is specified, so it does not make sense to complete them. git checkout, however, does not disable the completion of DWIM remote branch names in this case. Add test cases for both git switch and git checkout showing the expected behavior. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: add tests showing subpar DWIM logic for switch/checkoutJacob Keller
When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: add test showing subpar git switch completionJacob Keller
When provided with no options, git switch only allows switching between branches. The one exception to this is the "Do What I Mean" logic that allows a unique remote branch name to be interpreted as a request to create a branch of the same name that is tracking that remote branch. Unfortunately, the logic for the completion of git switch results in completing not just branch names, but also pseudorefs like HEAD, tags, and fully specified <remote>/<branch> references. For example, we currently complete the following: $git switch <TAB> HEAD branch-in-other master master-in-other matching-branch matching-tag other/branch-in-other other/master-in-other Indeed, if one were to attempt to use git switch with some of these provided options, git will reject the request: $git switch HEAD fatal: a branch is expected, got 'HEAD $git switch matching-tag fatal: a branch is expected, got tag 'matching-tag' $git switch other/branch-in-other fatal: a branch is expected, got remote branch 'other/branch-in-other' Ideally, git switch without options ought to complete only words which will be accepted. Without options, this means to list local branch names and the unique remote branch names without their remote name pre-pended. $git switch <TAB> branch-in-other master master-in-other matching-branch Add a test case that highlights this subpar completion. Also add a similar test for git checkout completion that shows that due to the complex nature of git checkout, it must complete all references. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-29Merge branch 'en/fill-directory-exponential'Junio C Hamano
The directory traversal code had redundant recursive calls which made its performance characteristics exponential with respect to the depth of the tree, which was corrected. * en/fill-directory-exponential: completion: fix 'git add' on paths under an untracked directory Fix error-prone fill_directory() API; make it only return matches dir: replace double pathspec matching with single in treat_directory() dir: include DIR_KEEP_UNTRACKED_CONTENTS handling in treat_directory() dir: replace exponential algorithm with a linear one dir: refactor treat_directory to clarify control flow dir: fix confusion based on variable tense dir: fix broken comment dir: consolidate treat_path() and treat_one_path() dir: fix simple typo in comment t3000: add more testcases testing a variety of ls-files issues t7063: more thorough status checking
2020-04-01completion: fix 'git add' on paths under an untracked directoryElijah Newren
As reported on the git mailing list, since git-2.25, git add untracked-dir/ has been tab completing to git add untracked-dir/./ The cause for this was that with commit b9670c1f5e (dir: fix checks on common prefix directory, 2019-12-19), git ls-files -o --directory untracked-dir/ (or the equivalent `git -C untracked-dir ls-files -o --directory`) began reporting untracked-dir/ instead of listing paths underneath that directory. It may also be worth noting that the real command in question was git -C untracked-dir ls-files -o --directory '*' which is equivalent to git ls-files -o --directory 'untracked-dir/*' which behaves the same for the purposes of this issue (the '*' can match the empty string), but becomes relevant for the proposed fix. At first, based on the report, I decided to try to view this as a regression and tried to find a way to recover the old behavior without breaking other stuff, or at least breaking as little as possible. However, in the end, I couldn't figure out a way to do it that wouldn't just cause lots more problems than it solved. The old behavior was a bug: * Although older git would avoid cleaning anything with `git clean -f .git`, it would wipe out everything under that direcotry with `git clean -f .git/`. Despite the difference in command used, this is relevant because the exact same change that fixed clean changed the behavior of ls-files. * Older git would report different results based solely on presence or absence of a trailing slash for $SUBDIR in the command `git ls-files -o --directory $SUBDIR`. * Older git violated the documented behavior of not recursing into directories that matched the pathspec when --directory was specified. * And, after all, commit b9670c1f5e (dir: fix checks on common prefix directory, 2019-12-19) didn't overlook this issue; it explicitly stated that the behavior of the command was being changed to bring it inline with the docs. (Also, if it helps, despite that commit being merged during the 2.25 series, this bug was not reported during the 2.25 cycle, nor even during most of the 2.26 cycle -- it was reported a day before 2.26 was released. So the impact of the change is at least somewhat small.) Instead of relying on a bug of ls-files in reporting the wrong content, change the invocation of ls-files used by git-completion to make it grab paths one depth deeper. Do this by changing '$DIR/*' (match $DIR/ plus 0 or more characters) into '$DIR/?*' (match $DIR/ plus 1 or more characters). Note that the '?' character should not be added when trying to complete a filename (e.g. 'git ls-files -o --directory "merge.c?*"' would not correctly return "merge.c" when such a file exists), so we have to make sure to add the '?' character only in cases where the path specified so far is a directory. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-30Merge branch 'sg/completion-worktree'Junio C Hamano
The command line completion (in contrib/) learned to complete subcommands and arguments to "git worktree". * sg/completion-worktree: completion: list paths and refs for 'git worktree add' completion: list existing working trees for 'git worktree' subcommands completion: simplify completing 'git worktree' subcommands and options completion: return the index of found word from __git_find_on_cmdline() completion: clean up the __git_find_on_cmdline() helper function t9902-completion: add tests for the __git_find_on_cmdline() helper
2020-01-15completion: return the index of found word from __git_find_on_cmdline()SZEDER Gábor
When using the __git_find_on_cmdline() helper function so far we've only been interested in which one of a set of words appear on the command line. To complete options for some of 'git worktree's subcommands in the following patches we'll need not only that, but the index of that word on the command line as well. Extend __git_find_on_cmdline() to optionally show the index of the found word on the command line (IOW in the $words array) when the '--show-idx' option is given. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15t9902-completion: add tests for the __git_find_on_cmdline() helperSZEDER Gábor
The following two patches will refactor and extend the __git_find_on_cmdline() helper function, so let's add a few tests first to make sure that its basic behavior doesn't change. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-25Merge branch 'am/pathspec-f-f-checkout'Junio C Hamano
A few more commands learned the "--pathspec-from-file" command line option. * am/pathspec-f-f-checkout: checkout, restore: support the --pathspec-from-file option doc: restore: synchronize <pathspec> description doc: checkout: synchronize <pathspec> description doc: checkout: fix broken text reference doc: checkout: remove duplicate synopsis add: support the --pathspec-from-file option cmd_add: prepare for next patch
2019-12-04checkout, restore: support the --pathspec-from-file optionAlexandr Miloslavskiy
Decisions taken for simplicity: 1) For now, `--pathspec-from-file` is declared incompatible with `--patch`, even when <file> is not `stdin`. Such use case it not really expected. 2) It is not allowed to pass pathspec in both args and file. `you must specify path(s) to restore` block was moved down to be able to test for `pathspec.nr` instead, because testing for `argc` is no longer correct. `git switch` does not support the new options because it doesn't expect `<pathspec>` arguments. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-01Merge branch 'en/doc-typofix'Junio C Hamano
Docfix. * en/doc-typofix: Fix spelling errors in no-longer-updated-from-upstream modules multimail: fix a few simple spelling errors sha1dc: fix trivial comment spelling error Fix spelling errors in test commands Fix spelling errors in messages shown to users Fix spelling errors in names of tests Fix spelling errors in comments of testcases Fix spelling errors in code comments Fix spelling errors in documentation outside of Documentation/ Documentation: fix a bunch of typos, both old and new
2019-11-10Merge branch 'dl/format-patch-cover-from-desc'Junio C Hamano
The branch description ("git branch --edit-description") has been used to fill the body of the cover letters by the format-patch command; this has been enhanced so that the subject can also be filled. * dl/format-patch-cover-from-desc: format-patch: teach --cover-from-description option format-patch: use enum variables format-patch: replace erroneous and condition
2019-11-10Fix spelling errors in names of testsElijah Newren
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in comments of testcasesElijah Newren
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-16format-patch: teach --cover-from-description optionDenton Liu
Before, when format-patch generated a cover letter, only the body would be populated with a branch's description while the subject would be populated with placeholder text. However, users may want to have the subject of their cover letter automatically populated in the same way. Teach format-patch to accept the `--cover-from-description` option and corresponding `format.coverFromDescription` config, allowing users to populate different parts of the cover letter (including the subject now). Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-30Merge branch 'en/filter-branch-deprecation'Junio C Hamano
Start discouraging the use of "git filter-branch". * en/filter-branch-deprecation: t9902: use a non-deprecated command for testing Recommend git-filter-repo instead of git-filter-branch t6006: simplify, fix, and optimize empty message test