kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Felipe Contreras	e9f2118ddf	completion: bash: fix for suboptions with value 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>	4 years ago
Philippe Blain	ca2d62b787	parse-options: don't complete option aliases by default 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>	4 years ago
Denton Liu	59d85a2a05	git-completion.bash: use $__git_cmd_idx in more places 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>	4 years ago
Sergey Organov	17c13e60fd	diff-merges: introduce log.diffMerges config variable 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>	4 years ago
Ævar Arnfjörð Bjarmason	73c01d25fe	tests: remove uses of GIT_TEST_GETTEXT_POISON=false 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 `38b9197a76` (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>	4 years ago
Felipe Contreras	5a067ba9d0	completion: add proper public __git_complete 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>	4 years ago
Felipe Contreras	0e02bdc17a	test: completion: add tests for __git_complete 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>	4 years ago
Johannes Schindelin	0007618107	t9902: use `main` as initial branch name In `8164360fc8` (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>	4 years ago
Felipe Contreras	b64b43d2f2	test: completion: fix typos Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	334afbc76f	tests: mark tests relying on the current default for `init.defaultBranch` 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>	4 years ago
Felipe Contreras	9414938c34	completion: bash: support recursive aliases 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>	4 years ago
Felipe Contreras	af806a2c24	zsh: update copyright notices Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	8164360fc8	t9902: prepare a test for the upcoming default branch name 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>	4 years ago
Denton Liu	64f1f58fe7	checkout: learn to respect checkout.guess 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>	4 years ago
Johannes Schindelin	f33f2d3d54	t9902: avoid using the branch name `master` 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>	4 years ago
Johannes Schindelin	6dca5dbf93	tests: reference `seen` wherever `pu` was referenced 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>	5 years ago
Jacob Keller	91439928ec	completion: improve handling of --orphan option of switch/checkout 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>	5 years ago
Jacob Keller	acb658fe7d	completion: improve handling of -c/-C and -b/-B in switch/checkout 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>	5 years ago
Jacob Keller	00e7bd2b00	completion: improve handling of --track in switch/checkout 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>	5 years ago
Jacob Keller	6d76a5cc7f	completion: improve handling of --detach in checkout 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>	5 years ago
Jacob Keller	68d97c7fdd	completion: improve completion for git switch with no options 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>	5 years ago
Jacob Keller	4e79adf4e5	completion: improve handling of DWIM mode for switch/checkout 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>	5 years ago
Jacob Keller	c81ca56bca	completion: add tests showing subpar switch/checkout --orphan logic 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>	5 years ago
Jacob Keller	7f59d60429	completion: add tests showing subpar -c/C argument completion 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>	5 years ago
Jacob Keller	b07d77a2ba	completion: add tests showing subpar -c/-C startpoint completion 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>	5 years ago
Jacob Keller	c55b99c3d3	completion: add tests showing subpar switch/checkout --track logic 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>	5 years ago
Jacob Keller	e69fb0a16a	completion: add tests showing subar checkout --detach logic 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>	5 years ago
Jacob Keller	ab58e90f8b	completion: add tests showing subpar DWIM logic for switch/checkout 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>	5 years ago
Jacob Keller	fab466f91d	completion: add test showing subpar git switch completion 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>	5 years ago
Elijah Newren	c0af173a13	completion: fix 'git add' on paths under an untracked directory 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>	5 years ago
SZEDER Gábor	367efd54b3	completion: return the index of found word from __git_find_on_cmdline() 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>	5 years ago
SZEDER Gábor	2712e91564	t9902-completion: add tests for the __git_find_on_cmdline() helper 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>	5 years ago
Alexandr Miloslavskiy	a9aecc7abb	checkout, restore: support the --pathspec-from-file option 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>	5 years ago
Elijah Newren	4dc8b1c114	Fix spelling errors in names of tests 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>	5 years ago
Elijah Newren	7a40cf1553	Fix spelling errors in comments of testcases 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>	5 years ago
Denton Liu	bf8e65b30b	format-patch: teach --cover-from-description option 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>	5 years ago
Elijah Newren	483e861111	t9902: use a non-deprecated command for testing t9902 had a list of three random porcelain commands as a sanity check, one of which was filter-branch. Since we are recommending people not use filter-branch, let's update this test to use rebase instead of filter-branch. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	5af9d5f6c8	completion: complete config variables and values for 'git clone --config=' Completing configuration sections and variable names for the stuck argument of 'git clone --config=<TAB>' requires a bit of extra care compared to doing the same for the unstuck argument of 'git clone --config <TAB>', because we have to deal with that '--config=' being part of the current word to be completed. Add an option to the __git_complete_config_variable_name_and_value() and in turn to the __git_complete_config_variable_name() helper functions to specify the current section/variable name to be completed, so they can be used even when completing the stuck argument of '--config='. __git_complete_config_variable_value() already has such an option, and thus no further changes were necessary to complete possible values after 'git clone --config=section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	dd33472831	completion: complete values of configuration variables after 'git -c var=' 'git config' expects a configuration variable's name and value in separate options, so we complete values as they stand on their own on the command line. 'git -c', however, expects them in a single option joined by a '=' character, so we should be able to complete values when they are following 'section.name=' in the same word. Add new options to the __git_complete_config_variable_value() function to allow callers to specify the current word to be completed and the configuration variable whose value is to be completed, and use these to complete possible values after 'git -c 'section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	e1e00089da	completion: complete configuration sections and variable names for 'git -c' 'git config' expects a configuration variable's name and value in separate arguments, so we let the __gitcomp() helper append a space character to each variable name by default, like we do for most other things (--options, refs, paths, etc.). 'git -c', however, expects them in a single option joined by a '=' character, i.e. 'section.name=value', so we should append a '=' character to each fully completed variable name, but no space, so the user can continue typing the value right away. Add an option to the __git_complete_config_variable_name() function to allow callers to specify an alternate suffix to add, and use it to append that '=' character to configuration variables. Update the __gitcomp() helper function to not append a trailing space to any completion words ending with a '=', not just to those option with a stuck argument. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	d9438873c4	completion: deduplicate configuration sections The number of configuration variables listed by the completion script grew quite when we started to auto-generate it from the documentation [1], so we now complete them in two steps: first we list only the section names, then the rest [2]. To get the section names we simply strip everything following the first dot in each variable name, resulting in a lot of repeated section names, because most sections contain more than one configuration variable. This is not a correctness issue in practice, because Bash's completion facilities remove all repetitions anyway, but these repetitions make testing a bit harder. Replace the small 'sed' script removing subsections and variable names with an 'awk' script that does the same, and in addition removes any repeated configuration sections as well (by first creating and filling an associative array indexed by all encountered configuration sections, and then iterating over this array and printing the indices, i.e. the unique section names). This change makes the failing 'git config - section' test in 't9902-completion.sh' pass. Note that this changes the order of section names in the output, and makes it downright undeterministic, but this is not an issue, because Bash sorts them before presenting them to the user, and our completion tests sort them as well before comparing with the expected output. Yeah, it would be simpler and shorter to just append '\| sort -u' to that command, but that would incur the overhead of one more external process and pipeline stage every time a user completes configuration sections. [1] `e17ca92637` (completion: drop the hard coded list of config vars, 2018-05-26) [2] `f22f682695` (completion: complete general config vars in two steps, 2018-05-27) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	7a09a8f093	completion: add tests for 'git config' completion The next patches will change/refactor the way we complete configuration variable names and values, so add a few tests to cover the basics, namely the completion of matching configuration sections, full variable names, and their values. Note that the test checking the completion of configuration sections is currently failing, though it's not a sign of an actual bug. If a section contains multiple variables, then that section is currently repeated as many times as the number of variables in there. This is not a correctness issue in practice, because Bash's completion facilities remove all repetitions anyway. Consequently, we could list all those repeated sections in the expected output of this test as well, but then it would have to be updated whenever a new configuration variable is added to those sections. Instead, list each matching configuration section only once, mark the test as failing for now, and the next patch will update the completion script to avoid those repetitions. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ævar Arnfjörð Bjarmason	1ff750b128	tests: make GIT_TEST_GETTEXT_POISON a boolean Change the GIT_TEST_GETTEXT_POISON variable from being "non-empty?" to being a more standard boolean variable. Since it needed to be checked in both C code and shellscript (via test -n) it was one of the remaining shellscript-like variables. Now that we have "env--helper" we can change that. There's a couple of tricky edge cases that arise because we're using git_env_bool() early, and the config-reading "env--helper". If GIT_TEST_GETTEXT_POISON is set to an invalid value die_bad_number() will die, but to do so it would usually call gettext(). Let's detect the special case of GIT_TEST_GETTEXT_POISON and always emit that message in the C locale, lest we infinitely loop. As seen in the updated tests in t0017-env-helper.sh there's also a caveat related to "env--helper" needing to read the config for trace2 purposes. Since the C_LOCALE_OUTPUT prerequisite is lazy and relies on "env--helper" we could get invalid results if we failed to read the config (e.g. because we'd loop on includes) when combined with e.g. "test_i18ngrep" wanting to check with "env--helper" if GIT_TEST_GETTEXT_POISON was true or not. I'm crossing my fingers and hoping that a test similar to the one I removed in the earlier "config tests: simplify include cycle test" change in this series won't happen again, and testing for this explicitly in "env--helper"'s own tests. This change breaks existing uses of e.g. GIT_TEST_GETTEXT_POISON=YesPlease, which we've documented in po/README and other places. As noted in [1] we might want to consider also accepting "YesPlease" in "env--helper" as a special-case. But as the lack of uproar over `6cdccfce1e` ("i18n: make GETTEXT_POISON a runtime option", 2018-11-08) demonstrates the audience for this option is a really narrow set of git developers, who shouldn't have much trouble modifying their test scripts, so I think it's better to deal with that minor headache now and make all the relevant GIT_TEST_* variables boolean in the same way than carry the "YesPlease" special-case forward. 1. https://public-inbox.org/git/xmqqtvckm3h8.fsf@gitster-ct.c.googlers.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	057ab54b66	completion: fix multiple command removals Commit `6532f3740b` ("completion: allow to customize the completable command list", 2018-05-20) tried to allow multiple space-separated entries in completion.commands. To do this, it copies each parsed token into a strbuf so that the result is NUL-terminated. However, for tokens starting with "-", it accidentally passes the original non-terminated string, meaning that only the final one worked. Switch to using the strbuf. Reported-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Todd Zullinger	402e3e1500	t9902: test multiple removals via completion.commands `6532f3740b` ("completion: allow to customize the completable command list", 2018-05-20) added the completion.commands config variable. Multiple commands may be added or removed, separated by a space. Demonstrate the failure of multiple removals. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Thomas Gummerer	091e04bc8c	checkout: introduce --{,no-}overlay option Currently 'git checkout' is defined as an overlay operation, which means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an entry in the index that matches <pathspec>, but that doesn't exist in <tree-ish>, that entry will not be removed from the index or the working tree. Introduce a new --{,no-}overlay option, which allows using 'git checkout' in non-overlay mode, thus removing files from the working tree if they do not exist in <tree-ish> but match <pathspec>. Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works this way, so no changes are needed for the patch mode. We disallow 'git checkout --overlay -p' to avoid confusing users who would expect to be able to force overlay mode in 'git checkout -p' this way. Untracked files are not affected by this change, so 'git checkout --no-overlay HEAD -- untracked' will not remove untracked from the working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/' doesn't delete all untracked files in dir/, but rather just resets the state of files that are known to git. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Chayoung You	6d54f528c7	completion: treat results of git ls-tree as file paths Let's say there are files named 'foo bar.txt', and 'abc def/test.txt' in repository. When following commands trigger a completion: git show HEAD:fo<Tab> git show HEAD:ab<Tab> The completion results in bash/zsh: git show HEAD:foo bar.txt git show HEAD:abc def/ Where the both of them have an unescaped space in paths, so they'll be misread by git. All entries of git ls-tree either a filename or a directory, so __gitcomp_file() is proper rather than __gitcomp_nl(). Note the commit `f12785a3`, which handles quoted paths properly. Like this case, we should dequote $cur_ for ?: case. For example, let's say there is untracked directory 'abc deg', then trigger a completion: git show HEAD:abc\ de<Tab> git show HEAD:'abc de<Tab> git show HEAD:"abc de<Tab> should uniquely complete 'abc def', but bash completes 'abc def' and 'abc deg' instead. In zsh, triggering a completion: git show HEAD:abc\ def/<Tab> should complete 'test.txt', but nothing comes. The both problems will be resolved by dequoting paths. __git_complete_revlist_file() passes arguments to __gitcomp_nl() where the first one is a list something like: abc def/Z foo bar.txt Z where Z is the mark of the EOL. - The trailing space of blob in __git ls-tree \| sed. It makes the completion results become: git show HEAD:foo\ bar.txt\ <CURSOR> So git will try to find a file named 'foo bar.txt ' instead. - The trailing slash of tree in __git ls-tree \| sed. It makes the completion results on zsh become: git show HEAD:abc\ def/ <CURSOR> So that the last space on command like should be removed on zsh to complete filenames under 'abc def/'. Signed-off-by: Chayoung You <yousbe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	0365b9ec59	t9902: 'send-email' test case requires PERL The oneline notwithstanding, `13374987dd` (completion: use _gitcompbuiltin for format-patch, 2018-11-03) changed also the way send-email options are completed, by asking the git send-email command itself what options it offers. Necessarily, this must fail when built with NO_PERL because send-email itself is a Perl script. Which means that we need the PERL prerequisite for the send-email test case in t9902. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	165293af3c	tests: send "bug in the test script" errors to the script's stderr Some of the functions in our test library check that they were invoked properly with conditions like this: test "$#" = 2 \|\| error "bug in the test script: not 2 parameters to test-expect-success" If this particular condition is triggered, then 'error' will abort the whole test script with a bold red error message [1] right away. However, under certain circumstances the test script will be aborted completely silently, namely if: - a similar condition in a test helper function like 'test_line_count' is triggered, - which is invoked from the test script's "main" shell [2], - and the test script is run manually (i.e. './t1234-foo.sh' as opposed to 'make t1234-foo.sh' or 'make test') [3] - and without the '--verbose' option, because the error message is printed from within 'test_eval_', where standard output is redirected either to /dev/null or to a log file. The only indication that something is wrong is that not all tests in the script are executed and at the end of the test script's output there is no "# passed all N tests" message, which are subtle and can easily go unnoticed, as I had to experience myself. Send these "bug in the test script" error messages directly to the test scripts standard error and thus to the terminal, so those bugs will be much harder to overlook. Instead of updating all ~20 such 'error' calls with a redirection, let's add a BUG() function to 'test-lib.sh', wrapping an 'error' call with the proper redirection and also including the common prefix of those error messages, and convert all those call sites [4] to use this new BUG() function instead. [1] That particular error message from 'test_expect_success' is printed in color only when running with or without '--verbose'; with '--tee' or '--verbose-log' the error is printed without color, but it is printed to the terminal nonetheless. [2] If such a condition is triggered in a subshell of a test, then 'error' won't be able to abort the whole test script, but only the subshell, which in turn causes the test to fail in the usual way, indicating loudly and clearly that something is wrong. [3] Well, 'error' aborts the test script the same way when run manually or by 'make' or 'prove', but both 'make' and 'prove' pay attention to the test script's exit status, and even a silently aborted test script would then trigger those tools' usual noticable error messages. [4] Strictly speaking, not all those 'error' calls need that redirection to send their output to the terminal, see e.g. 'test_expect_success' in the opening example, but I think it's better to be consistent. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Nguyễn Thái Ngọc Duy	be4908f103	checkout: disambiguate dwim tracking branches and local files When checkout dwim is added in [1], it is restricted to only dwim when certain conditions are met and fall back to default checkout behavior otherwise. It turns out falling back could be confusing. One of the conditions to turn git checkout frotz to git checkout -b frotz origin/frotz is that frotz must not exist as a file. But when the user comes to expect "git checkout frotz" to create the branch "frotz" and there happens to be a file named "frotz", git's silently reverting "frotz" file content is not helping. This is reported in Git mailing list [2] and even used as an example of "Git is bad" elsewhere [3]. We normally try to do the right thing, but when there are multiple "right things" to do, it's best to leave it to the user to decide. Check this case, ask the user to to disambiguate: - "git checkout -- foo" will check out path "foo" - "git checkout foo --" will dwim and create branch "foo" [4] For users who do not want dwim, use --no-guess. It's useless in this particular case because "git checkout --no-guess foo --" will just fail. But it could be used by scripts. [1] `70c9ac2f19` (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz" - 2009-10-18) [2] https://public-inbox.org/git/CACsJy8B2TVr1g+k+eSQ=pBEO3WN4_LtgLo9gpur8X7Z9GOFL_A@mail.gmail.com/ [3] https://news.ycombinator.com/item?id=18230655 [4] `a047fafc78` (checkout: allow dwim for branch creation for "git checkout $branch --" - 2013-10-18) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago

1 2 3 4

153 Commits (2cdc292b3160e2bd80c3a9d24eff3afe29a2a46d)