summaryrefslogtreecommitdiff
path: root/t/t9902-completion.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-03-23t9902: disable test on the list of merge-strategies under GETTEXT_POISONLibravatar Junio C Hamano1-1/+1
The code to learn the list of merge strategies from the output of "git merge -s help" forces C locale, so that it can notice the message shown to indicate where the list starts in the output. However, GETTEXT_POISON build corrupts its output even when run in the C locale, and we cannot expect this test to succeed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-22completion: clear cached --options when sourcing the completion scriptLibravatar SZEDER Gábor1-0/+31
The established way to update the completion script in an already running shell is to simply source it again: this brings in any new --options and features, and clears caching variables. E.g. it clears the variables caching the list of (all|porcelain) git commands, so when they are later lazy-initialized again, then they will list and cache any newly installed commmands as well. Unfortunately, since d401f3debc (git-completion.bash: introduce __gitcomp_builtin, 2018-02-09) and subsequent patches this doesn't work for a lot of git commands' options. To eliminate a lot of hard-to-maintain hard-coded lists of options, those commits changed the completion script to use a bunch of programmatically created and lazy-initialized variables to cache the options of those builtin porcelain commands that use parse-options. These variables are not cleared upon sourcing the completion script, therefore they continue caching the old lists of options, even when some commands recently learned new options or when deprecated options were removed. Always 'unset' these variables caching the options of builtin commands when sourcing the completion script. Redirect 'unset's stderr to /dev/null, because ZSH's 'unset' complains if it's invoked without any arguments, i.e. no variables caching builtin's options are set. This can happen, if someone were to source the completion script twice without completing any --options in between. Bash stays silent in this case. Add tests to ensure that these variables are indeed cleared when the completion script is sourced; not just the variables caching options, but all other caching variables, i.e. the variables caching commands, porcelain commands and merge strategies as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-09completion: use __gitcomp_builtin in _git_checkoutLibravatar Nguyễn Thái Ngọc Duy1-5/+7
The new completable options are: --ignore-other-worktrees --progress Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-25completion: add remaining flags to checkoutLibravatar Thomas Braun1-0/+4
In the commits 1fc458d9 (builtin/checkout: add --recurse-submodules switch, 2017-03-14), 08d595dc (checkout: add --ignore-skip-worktree-bits in sparse checkout mode, 2013-04-13) and 32669671 (checkout: introduce --detach synonym for "git checkout foo^{commit}", 2011-02-08) checkout gained new flags but the completion was not updated, although these flags are useful completions. Add them. The flags --force and --ignore-other-worktrees are not added as they are potentially dangerous. The flags --progress and --no-progress are only useful for scripting and are therefore also not included. Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-23completion: expand "push --delete <remote> <ref>" for refs on that <remote>Libravatar Ævar Arnfjörð Bjarmason1-0/+34
Change the completion of "push --delete <remote> <ref>" to complete refs on that <remote>, not all refs. Before this cloning git.git and doing "git push --delete origin p<TAB>" will complete nothing, since a fresh clone of git.git will have no "pu" branch, whereas origin/p<TAB> will uselessly complete origin/pu, but fully qualified references aren't accepted by "--delete". Now p<TAB> will complete as "pu". The completion of giving --delete later, e.g. "git push origin --delete p<TAB>" remains unchanged, this is a bug, but is a general existing limitation of the bash completion, and not how git-push is documented, so I'm not fixing that case, but adding a failing TODO test for it. The testing code was supplied by SZEDER Gábor in <20170421122832.24617-1-szeder.dev@gmail.com> with minor setup modifications on my part. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Test-code-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: fill COMPREPLY directly when completing refsLibravatar SZEDER Gábor1-0/+27
__gitcomp_nl() iterates over all the possible completion words it gets as argument - filtering matching words, - appending a trailing space to each matching word (in all but two cases), - prepending a prefix to each matching word (when completing words after e.g. '--option=<TAB>' or 'master..<TAB>'), and - adding each matching word to the COMPREPLY array. This takes a while when a lot of refs are passed to __gitcomp_nl(). The previous changes in this series ensure that __git_refs() lists only refs matching the current word to be completed, making a second filtering in __gitcomp_nl() redundant. Adding the necessary prefix and suffix could be done in __git_refs() as well: - When refs come from 'git for-each-ref', then that prefix and suffix could be added much more efficiently using a 'git for-each-ref' format containing said prefix and suffix. Care should be taken, though, because that prefix might contain 'for-each-ref' format specifiers as part of the left hand side of a '..' range or '...' symmetric difference notation or fetch/push/etc. refspec, e.g. 'git log "evil-%(refname)..br<TAB>'. Doubling every '%' in the prefix will prevent 'git for-each-ref' from interpolating any of those contained specifiers. - When refs come from 'git ls-remote', then that prefix and suffix can be added in the shell loop that has to process 'git ls-remote's output anyway. - Finally, the prefix and suffix can be added to that handful of potentially matching symbolic and pseudo refs right away in the shell loop listing them. And then all what is still left to do is to assign a bunch of newline-separated words to a shell array, which can be done without a shell loop iterating over each word, basically making all of __gitcomp_nl() unnecessary for refs completion. Add the helper function __gitcomp_direct() to fill the COMPREPLY array with prefiltered and preprocessed words without any additional processing, without a shell loop, with just one single compound assignment. Modify __git_refs() to accept prefix and suffix parameters and add them to each and every listed ref as described above. Modify __git_complete_refs() to pass the prefix and suffix parameters to __git_refs() and to feed __git_refs()'s output to __gitcomp_direct() instead of __gitcomp_nl(). This speeds up refs completion when there are a lot of refs matching the current word to be completed. Listing all branches for completion in a repo with 100k local branches, all packed, best of five: On Linux, near the beginning of this series, for reference: $ time __git_complete_refs real 0m2.028s user 0m1.692s sys 0m0.344s Before this patch: real 0m1.135s user 0m1.112s sys 0m0.024s After: real 0m0.367s user 0m0.352s sys 0m0.020s On Windows, near the beginning: real 0m13.078s user 0m1.609s sys 0m0.060s Before this patch: real 0m2.093s user 0m1.641s sys 0m0.060s After: real 0m0.683s user 0m0.203s sys 0m0.076s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: let 'for-each-ref' and 'ls-remote' filter matching refsLibravatar SZEDER Gábor1-0/+124
When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: support excluding full refsLibravatar SZEDER Gábor1-0/+31
Commit 49416ad22 (completion: support excluding refs, 2016-08-24) made possible to complete short refs with a '^' prefix. Extend the support to full refs to make completing '^refs/...' work. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: support completing fully qualified non-fast-forward refspecsLibravatar SZEDER Gábor1-0/+68
After 'git fetch <remote> <TAB>' our completion script offers refspecs that will fetch to a local branch with the same name as in the remote repository, e.g. 'master:master'. This also completes non-fast-forward refspecs, i.e. after a '+' prefix like '+master:master', and fully qualified refspecs, e.g. 'refs/heads/master:refs/heads/master'. However, it does not complete non-fast-forward fully qualified refspecs (or fully qualified refspecs following any other prefix, e.g. '--option=', though currently no git command supports such an option, but third party git commands might). These refspecs are listed by the __git_refs2() function, which is just a thin wrapper iterating over __git_refs()'s output, turning each listed ref into a refspec. Now, it's certainly possible to modify __git_refs2() and its callsite to pass an extra parameter containing only the ref part of the current word to be completed (to follow suit of the previous commit) to deal with prefixed fully qualified refspecs as well. Unfortunately, keeping the current behavior unchanged in the "no extra parameter" case brings in a bit of subtlety, which makes the resulting code ugly and compelled me to write a 8-line long comment in the proof of concept. Not good. However, since the callsite has to be modified for proper functioning anyway, we might as well leave __git_refs2() as is and introduce a new helper function without backwards compatibility concerns. Add the new function __git_complete_fetch_refspecs() that has all the necessary parameters to do the right thing in all cases mentioned above, including non-fast-forward fully qualified refspecs. This new function can also easier benefit from optimizations coming later in this patch series. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: support completing full refs after '--option=refs/<TAB>'Libravatar SZEDER Gábor1-0/+31
Completing full refs currently only works when the full ref stands on in its own on the command line, but doesn't work when the current word to be completed contains a prefix before the full ref, e.g. '--option=refs/<TAB>' or 'master..refs/bis<TAB>'. The reason is that __git_refs() looks at the current word to be completed ($cur) as a whole to decide whether it has to list full (if it starts with 'refs/') or short refs (otherwise). However, $cur also holds said '--option=' or 'master..' prefixes, which of course throw off this decision. Luckily, the default action is to list short refs, that's why completing short refs happens to work even after a 'master..<TAB>' prefix and similar cases. Pass only the ref part of the current word to be completed to __git_refs() as a new positional parameter, so it can make the right decision even if the whole current word contains some kind of a prefix. Make this new parameter the 4. positional parameter and leave the 3. as an ignored placeholder for now (it will be used later in this patch series). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: wrap __git_refs() for better option parsingLibravatar SZEDER Gábor1-0/+106
__git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: cache the path to the repositoryLibravatar SZEDER Gábor1-58/+103
After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: extract repository discovery from __gitdir()Libravatar SZEDER Gábor1-6/+16
To prepare for caching the path to the repository in the following commit, extract the repository discovering part of __gitdir() into the __git_find_repo_path() helper function, which stores the found path in the $__git_repo_path variable instead of printing it. Make __gitdir() a wrapper around this new function. Declare $__git_repo_path local in the toplevel completion functions __git_main() and __gitk_main() to ensure that it never leaks into the environment and influences subsequent completions (though this isn't necessary right now, as __gitdir() is still only executed in subshells, but will matter for the following commit). Adjust tests checking __gitdir() or any other completion function calling __gitdir() to perform those checks in a subshell to prevent $__git_repo_path from leaking into the test environment. Otherwise leave the tests unchanged to demonstrate that this change doesn't alter __gitdir()'s behavior. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: respect 'git -C <path>'Libravatar SZEDER Gábor1-0/+87
'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: fix completion after 'git -C <path>'Libravatar SZEDER Gábor1-1/+6
The main completion function finds the name of the git command by iterating through all the words on the command line in search for the first non-option-looking word. As it is not aware of 'git -C's mandatory path argument, if the '-C <path>' option is present, 'path' will be the first such word and it will be mistaken for a git command. This breaks completion in various ways: - If 'path' happens to match one of the commands supported by the completion script, then options of that command will be offered. - If 'path' doesn't match a supported command and doesn't contain any characters not allowed in Bash identifier names, then the completion script does basically nothing and Bash in turn falls back to filename completion for all subsequent words. - Otherwise, if 'path' does contain such an unallowed character, then it leads to a more or less ugly error message in the middle of the command line. The standard '/' directory separator is such a character, and it happens to trigger one of the uglier errors: $ git -C some/path <TAB>sh.exe": declare: `_git_some/path': not a valid identifier error: invalid key: alias.some/path Fix this by skipping 'git -C's mandatory path argument while iterating over the words on the command line. Extend the relevant test with this case and, while at it, with cases that needed similar treatment in the past ('--git-dir', '-c', '--work-tree' and '--namespace'). Additionally, silence the standard error of the 'declare' builtins looking for the completion function associated with the git command and of the 'git config' query for the aliased command. So if git ever learns a new option with a mandatory argument in the future, then, though the completion script will again misbehave, at least the command line will not be utterly disrupted by those error messages. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: list short refs from a remote given as a URLLibravatar SZEDER Gábor1-3/+3
e832f5c09680 (completion: avoid ls-remote in certain scenarios, 2013-05-28) turned a 'git ls-remote <remote>' query into a 'git for-each-ref refs/remotes/<remote>/' to improve responsiveness of remote refs completion by avoiding potential network communication. However, it inadvertently made impossible to complete short refs from a remote given as a URL, e.g. 'git fetch git://server.com/repo.git <TAB>', because there is, of course, no such thing as 'refs/remotes/git://server.com/repo.git'. Since the previous commit we tell apart configured remotes, i.e. those that can have a hierarchy under 'refs/remotes/', from others that don't, including remotes given as URL, so we know when we can't use the faster 'git for-each-ref'-based approach. Resurrect the old, pre-e832f5c09680 'git ls-remote'-based code for the latter case to support listing short refs from remotes given as a URL. The code is slightly updated from the original to - take into account the path to the repository given on the command line (if any), and - omit 'ORIG_HEAD' from the query, as 'git ls-remote' will never list it anyway. When the remote given to __git_refs() doesn't exist, then it will be handled by this resurrected 'git ls-remote' query. This code path doesn't list 'HEAD' unconditionally, which has the nice side effect of fixing two more expected test failures. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: don't list 'HEAD' when trying refs completion outside of a repoLibravatar SZEDER Gábor1-1/+1
When refs completion is attempted while not in a git repository, the completion script offers 'HEAD' erroneously. Check early in __git_refs() that there is either a repository or a remote to work on, and return early if neither is given. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: list refs from remote when remote's name matches a directoryLibravatar SZEDER Gábor1-1/+10
If the remote given to __git_refs() happens to match both the name of a configured remote and the name of a directory in the current working directory, then that directory is assumed to be a git repository, and listing refs from that directory will be attempted. This is wrong, because in such a situation git commands (e.g. 'git fetch|pull|push <remote>' whom these refs will eventually be passed to) give precedence to the configured remote. Therefore, __git_refs() should list refs from the configured remote as well. Add the helper function __git_is_configured_remote() that checks whether its argument matches the name of a configured remote. Use this helper to decide how to handle the remote passed to __git_refs(). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: respect 'git --git-dir=<path>' when listing remote refsLibravatar SZEDER Gábor1-2/+2
In __git_refs() the git commands listing refs, both short and full, from a given remote repository are run without giving them the path to the git repository which might have been specified on the command line via 'git --git-dir=<path>'. This is bad, those git commands should access the 'refs/remotes/<remote>/' hierarchy or the remote and credentials configuration in that specified repository. Use the __gitdir() helper only to find the path to the .git directory and pass the resulting path to the 'git ls-remote' and 'for-each-ref' executions that list remote refs. While modifying that 'for-each-ref' line, remove the superfluous disambiguating doubledash. Don't use __gitdir() to check that the given remote is on the file system: basically it performs only a single if statement for us at the considerable cost of fork()ing a subshell for a command substitution. We are better off to perform all the necessary checks of the remote in __git_refs(). Though __git_refs() was the last remaining callsite that passed a remote to __gitdir(), don't delete __gitdir()'s remote-handling part yet, just in case some users' custom completion scriptlets depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: ensure that the repository path given on the command line existsLibravatar SZEDER Gábor1-0/+8
The __gitdir() helper function prints the path to the git repository to its stdout or stays silent and returns with error when it can't find a repository or when the repository given via $GIT_DIR doesn't exist. This is not the case, however, when the path in $__git_dir, i.e. the path to the repository specified on the command line via 'git --git-dir=<path>', doesn't exist: __gitdir() still outputs it as if it were a real existing repository, making some completion functions believe that they operate on an existing repository. Check that the path in $__git_dir exists and return with error without printing anything to stdout if it doesn't. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion tests: add tests for the __git_refs() helper functionLibravatar SZEDER Gábor1-1/+264
Check how __git_refs() lists refs in different scenarios, i.e. - short and full refs, - from a local or from a remote repository, - remote specified via path, name or URL, - with or without a repository specified on the command line, - non-existing remote, - unique remote branches for 'git checkout's tracking DWIMery, - not in a git repository, and - interesting combinations of the above. Seven of these tests expect failure, mostly demonstrating bugs related to listing refs from a remote repository: - ignoring the repository specified on the command line (2 tests), - listing refs from the wrong place when the name of a configured remote happens to match a directory, - listing only 'HEAD' but no short refs from a remote given as URL, - listing 'HEAD' even from non-existing remotes (2 tests), and - listing 'HEAD' when not in a repository. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion tests: check __gitdir()'s output in the error casesLibravatar SZEDER Gábor1-3/+5
The __gitdir() helper function shouldn't output anything if not in a git repository. The relevant tests only checked its error code, so extend them to ensure that there's no output. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion tests: consolidate getting path of current working directoryLibravatar SZEDER Gábor1-23/+21
Some tests of the __gitdir() helper function use the $TRASH_DIRECTORY variable in direct path comparisons. In general this should be avoided, because it might contain symbolic links. There happens to be no issues with this here, however, because those tests use $TRASH_DIRECTORY both for specifying the expected result and for specifying input which in turn is just 'echo'ed verbatim. Other __gitdir() tests ask for the path of the trash directory by running $(pwd -P) in each test, sometimes even twice in a single test. Run $(pwd) only once at the beginning of the test script to store the path of the trash directory in a variable, and use that variable in all __gitdir() tests. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion tests: make the $cur variable local to the test helper functionsLibravatar SZEDER Gábor1-2/+2
The test helper functions test_gitcomp() and test_gitcomp_nl() leak the $cur variable into the test environment. Since this variable has a special role in the Bash completion script (it holds the word currently being completed) it influences the behavior of most completion functions and thus this leakage could interfere with subsequent tests. Although there are no such issues in the current tests, early versions of the new tests that will be added later in this series suffered because of this. It's better to play safe and declare $cur local in those test helper functions. 'local' is bashism, of course, but the tests of the Bash completion script are run under Bash anyway, and there are already other variables declared local in this test script. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion tests: don't add test cruft to the test repositoryLibravatar SZEDER Gábor1-3/+3
While preparing commits, three tests added newly created files to the index using 'git add .', which added not only the files in question but leftover test cruft from previous tests like the files 'expected' and 'actual' as well. Luckily, this had no effect on the tests' correctness. Add only the files we are actually interested in. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-16t: use nongit() function where applicableLibravatar Jeff King1-6/+1
Many tests want to run a command outside of any git repo; with the nongit() function this is now a one-liner. It saves a few lines, but more importantly, it's immediately obvious what the code is trying to accomplish. This doesn't convert every such case in the test suite; it just covers those that want to do a one-off command. Other cases, such as the ones in t4035, are part of a larger scheme of outside-repo files, and it's less confusing for them to stay consistent with the surrounding tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12completion: simplify query for config variablesLibravatar SZEDER Gábor1-0/+12
To get the name of all config variables in a given section we perform a 'git config --get-regex' query for all config variables containing the name of that section, and then filter its output through a case statement to throw away those that though contain but don't start with the given section. Modify the regex to match only at the beginning, so the case statement becomes unnecessary and we can get rid of it. Add a test to check that a match in the middle doesn't fool us. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12completion: add a helper function to get config variablesLibravatar SZEDER Gábor1-0/+22
Currently there are a few completion functions that perform similar 'git config' queries and filtering to get config variable names: the completion of pretty aliases, aliases, and remote groups for 'git remote update'. Unify those 'git config' queries in a helper function to eliminate code duplication. Though the helper functions to get pretty aliases and alieses are reduced to mere one-liner wrappers around the newly added function, keep these helpers still, because users' completion functions out there might depend on them. And they keep their callers a tad easier to read, too. Add tests for the pretty alias and alias helper to show that they work as before; not for the remote groups query, though, because that's not extracted into a helper function and it's not worth the effort to do so for a sole callsite. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix severe &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, in a location which causes a significant portion of the test to be missed (e.g., the test effectively does nothing, or consists of a long string of actions and output comparisons, and we throw away the exit code of at least one part of the string). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06completion: add a test for __git_remotes() helper functionLibravatar SZEDER Gábor1-0/+19
The test checks that both remotes under '$GIT_DIR/remotes' and remotes in the config file are listed. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21t9902: mingw-specific fix for gitfile link filesLibravatar Pat Thoyts1-4/+13
The path in a .git platform independent link file needs to be absolute and under mingw we need it to be a windows type path, not a unix style path so it should start with a drive letter and not a /. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13completion: handle '!f() { ... }; f' and "!sh -c '...' -" aliasesLibravatar Steffen Prohaska1-0/+27
'!f() { ... }; f' and "!sh -c '....' -" are recommended patterns for declaring more complex aliases (see git wiki [1]). This commit teaches the completion to handle them. When determining which completion to use for an alias, an opening brace or single quote is now skipped, and the search for a git command is continued. For example, the aliases '!f() { git commit ... }' or "!sh -c 'git commit ...'" now trigger commit completion. Previously, the search stopped on the opening brace or quote, and the completion tried it to determine how to complete, which obviously was useless. The null command ':' is now skipped, so that it can be used as a workaround to declare the desired completion style. For example, the aliases !f() { : git commit ; if ... } f !sh -c ': git commit; if ...' - now trigger commit completion. Shell function declarations now work with or without space before the parens, i.e. '!f() ...' and '!f () ...' both work. [1] https://git.wiki.kernel.org/index.php/Aliases Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-21t9902-completion.sh: old Bash still does not support array+=('') notationLibravatar Brandon Casey1-1/+1
Old Bash (3.0) which is distributed with RHEL 4.X and other ancient platforms that are still in wide use, does not understand the array+=() notation. Let's use an explicit assignment to the new array element which works everywhere, like: array[${#array[@]}+1]='' The right-hand side '' is not strictly necessary, but in this case I think it is more clear. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12Merge branch 'tr/test-lint-no-export-assignment-in-shell'Libravatar Junio C Hamano1-1/+1
* tr/test-lint-no-export-assignment-in-shell: test-lint: detect 'export FOO=bar' t9902: fix 'test A == B' to use = operator
2013-07-11Merge branch 'jk/bash-completion'Libravatar Junio C Hamano1-0/+1
* jk/bash-completion: completion: learn about --man-path completion: handle unstuck form of base git options
2013-07-08t9902: fix 'test A == B' to use = operatorLibravatar Thomas Rast1-1/+1
The == operator as an alias to = is not POSIX. This doesn't actually matter for the execution of the script, because it only runs when the shell is bash. However, it trips up test-lint, so it's nicer to use the standard form. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-30completion: learn about --man-pathLibravatar John Keeping1-0/+1
Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24completion, bash prompt: move __gitdir() tests to completion test suiteLibravatar SZEDER Gábor1-0/+134
Currently __gitdir() is duplicated in the git completion and prompt scripts, while its tests are in the prompt test suite. This patch series is about to change __git_ps1() in a way that it won't need __gitdir() anymore and __gitdir() will be removed from the prompt script. So move all __gitdir() tests from the prompt test suite over to the completion test suite. Update the setup tests so that they perform only those steps that are necessary for each test suite. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-04-27completion: document tilde expansion failure in testsLibravatar Felipe Contreras1-0/+9
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: add file completion testsLibravatar Felipe Contreras1-0/+68
The commit fea16b4 (git-completion.bash: add support for path completion) introduced quite a few changes, without the usual tests. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-14completion: get rid of compgenLibravatar Felipe Contreras1-3/+3
The functionality we use from compgen is not much, we can do the same manually, with drastic improvements in speed, especially when dealing with only a few words. This patch also has the sideffect that brekage reported by Jeroen Meijer and SZEDER Gábor gets fixed because we no longer expand the resulting words. Here are some numbers filtering N amount of words: == 1 == original: 0.002s new: 0.000s == 10 == original: 0.002s new: 0.000s == 100 == original: 0.003s new: 0.002s == 1000 == original: 0.012s new: 0.011s == 10000 == original: 0.056s new: 0.066s == 100000 == original: 2.669s new: 0.622s If the results are not narrowed: == 1 == original: 0.002s new: 0.000s == 10 == original: 0.002s new: 0.001s == 100 == original: 0.004s new: 0.004s == 1000 == original: 0.020s new: 0.015s == 10000 == original: 0.101s new: 0.355s == 100000 == original: 2.850s new: 31.941s So, unless 'git checkout <tab>' usually gives you more than 10000 results, you'll get an improvement :) Other possible solutions perform better after 1000 words, but worst if less than that: COMPREPLY=($(awk -v cur="$3" -v pre="$2" -v suf="$4" '$0 ~ cur { print pre$0suf }' <<< "$1" )) COMPREPLY=($(printf -- "$2%s$4\n" $1 | grep "^$2$3")) Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-14completion: add __gitcomp_nl testsLibravatar Felipe Contreras1-0/+60
Original patch by SZEDER Gábor. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12completion: trivial test improvementLibravatar Felipe Contreras1-1/+2
Instead of passing a dummy "", let's check if the last character is a space, and then move the _cword accordingly. Apparently we were passing "" all the way to compgen, which fortunately expanded it to nothing. Lets do the right thing though. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24t9902: protect test from stray build artifactsLibravatar Junio C Hamano1-1/+24
When you have random build artifacts in your build directory, left behind by running "make" while on another branch, the "git help -a" command run by __git_list_all_commands in the completion script that is being tested does not have a way to know that they are not part of the subcommands this build will ship. Such extra subcommands may come from the user's $PATH. They will interfere with the tests that expect a certain prefix to uniquely expand to a known completion. Instrument the completion script and give it a way for us to tell what (subset of) subcommands we are going to ship. Also add a test to "git --help <prefix><TAB>" expansion. It needs to show not just commands but some selected documentation pages. Based on an idea by Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29Merge branch 'fc/completion-test-simplification'Libravatar Junio C Hamano1-82/+52
Clean up completion tests. Use of conslidated helper may make instrumenting one particular test during debugging of the test itself, but I think that issue should be addressed in some other way (e.g. making sure individual tests in 9902 can be skipped). * fc/completion-test-simplification: completion: simplify __gitcomp() test helper completion: refactor __gitcomp related tests completion: consolidate test_completion*() tests completion: simplify tests using test_completion_long() completion: standardize final space marker in tests completion: add comment for test_completion()
2012-11-16completion: simplify __gitcomp() test helperLibravatar Felipe Contreras1-10/+5
By using print_comp as suggested by SZEDER Gábor. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-16completion: refactor __gitcomp related testsLibravatar Felipe Contreras1-50/+28
Remove lots of duplicated code; no functional changes intended. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-16completion: consolidate test_completion*() testsLibravatar Felipe Contreras1-17/+14
No need to have two versions; if a second argument is specified, use that, otherwise use stdin. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-16completion: simplify tests using test_completion_long()Libravatar Felipe Contreras1-6/+3
No need to duplicate that functionality. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-16completion: standardize final space marker in testsLibravatar Felipe Contreras1-14/+13
The rest of the code uses ' Z$'. Lets use that for test_completion_long() as well. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>