summaryrefslogtreecommitdiff
path: root/t/t9902-completion.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-03-07Merge branch 'tg/checkout-no-overlay'Libravatar Junio C Hamano1-0/+1
"git checkout --no-overlay" can be used to trigger a new mode of checking out paths out of the tree-ish, that allows paths that match the pathspec that are in the current index and working tree and are not in the tree-ish. * tg/checkout-no-overlay: revert "checkout: introduce checkout.overlayMode config" checkout: introduce checkout.overlayMode config checkout: introduce --{,no-}overlay option checkout: factor out mark_cache_entry_for_checkout function checkout: clarify comment read-cache: add invalidate parameter to remove_marked_cache_entries entry: support CE_WT_REMOVE flag in checkout_entry entry: factor out unlink_entry function move worktree tests to t24*
2019-01-18Merge branch 'cy/zsh-completion-SP-in-path'Libravatar Junio C Hamano1-5/+5
With zsh, "git cmd path<TAB>" was completed to "git cmd path name" when the completed path has a special character like SP in it, without any attempt to keep "path name" a single filename. This has been fixed to complete it to "git cmd path\ name" just like Bash completion does. * cy/zsh-completion-SP-in-path: completion: treat results of git ls-tree as file paths zsh: complete unquoted paths with spaces correctly
2019-01-08checkout: introduce --{,no-}overlay optionLibravatar Thomas Gummerer1-0/+1
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>
2019-01-04Merge branch 'nd/checkout-dwim-fix'Libravatar Junio C Hamano1-1/+2
"git checkout frotz" (without any double-dash) avoids ambiguity by making sure 'frotz' cannot be interpreted as a revision and as a path at the same time. This safety has been updated to check also a unique remote-tracking branch 'frotz' in a remote, when dwimming to create a local branch 'frotz' out of a remote-tracking branch 'frotz' from a remote. * nd/checkout-dwim-fix: checkout: disambiguate dwim tracking branches and local files
2019-01-03completion: treat results of git ls-tree as file pathsLibravatar Chayoung You1-5/+5
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>
2018-12-14t9902: 'send-email' test case requires PERLLibravatar Johannes Schindelin1-1/+1
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>
2018-11-20tests: send "bug in the test script" errors to the script's stderrLibravatar SZEDER Gábor1-1/+1
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>
2018-11-14checkout: disambiguate dwim tracking branches and local filesLibravatar Nguyễn Thái Ngọc Duy1-1/+2
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>
2018-11-09i18n: make GETTEXT_POISON a runtime optionLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON test parameter to only be a GIT_TEST_GETTEXT_POISON=<non-empty?> runtime parameter, to be consistent with other parameters documented in "Running tests with special setups" in t/README. When I added GETTEXT_POISON in bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) I was concerned with ensuring that the _() function would get constant folded if NO_GETTEXT was defined, and likewise that GETTEXT_POISON would be compiled out unless it was defined. But as the benchmark in my [1] shows doing a one-off runtime getenv("GIT_TEST_[...]") is trivial, and since GETTEXT_POISON was originally added the GIT_TEST_* env variables have become the common idiom for turning on special test setups. So change GETTEXT_POISON to work the same way. Now the GETTEXT_POISON=YesPlease compile-time option is gone, and running the tests with GIT_TEST_GETTEXT_POISON=[YesPlease|] can be toggled on/off without recompiling. This allows for conditionally amending tests to test with/without poison, similar to what 859fdc0c3c ("commit-graph: define GIT_TEST_COMMIT_GRAPH", 2018-08-29) did for GIT_TEST_COMMIT_GRAPH. Do some of that, now we e.g. always run the t0205-gettext-poison.sh test. I did enough there to remove the GETTEXT_POISON prerequisite, but its inverse C_LOCALE_OUTPUT is still around, and surely some tests using it can be converted to e.g. always set GIT_TEST_GETTEXT_POISON=. Notes on the implementation: * We still compile a dedicated GETTEXT_POISON build in Travis CI. Perhaps this should be revisited and integrated into the "linux-gcc" build, see ae59a4e44f ("travis: run tests with GIT_TEST_SPLIT_INDEX", 2018-01-07) for prior art in that area. Then again maybe not, see [2]. * We now skip a test in t0000-basic.sh under GIT_TEST_GETTEXT_POISON=YesPlease that wasn't skipped before. This test relies on C locale output, but due to an edge case in how the previous implementation of GETTEXT_POISON worked (reading it from GIT-BUILD-OPTIONS) wasn't enabling poison correctly. Now it does, and needs to be skipped. * The getenv() function is not reentrant, so out of paranoia about code of the form: printf(_("%s"), getenv("some-env")); call use_gettext_poison() in our early setup in git_setup_gettext() so we populate the "poison_requested" variable in a codepath that's won't suffer from that race condition. * We error out in the Makefile if you're still saying GETTEXT_POISON=YesPlease to prompt users to change their invocation. * We should not print out poisoned messages during the test initialization itself to keep it more readable, so the test library hides the variable if set in $GIT_TEST_GETTEXT_POISON_ORIG during setup. See [3]. See also [4] for more on the motivation behind this patch, and the history of the GETTEXT_POISON facility. 1. https://public-inbox.org/git/871s8gd32p.fsf@evledraar.gmail.com/ 2. https://public-inbox.org/git/20181102163725.GY30222@szeder.dev/ 3. https://public-inbox.org/git/20181022202241.18629-2-szeder.dev@gmail.com/ 4. https://public-inbox.org/git/878t2pd6yu.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20Merge branch 'wc/make-funnynames-shared-lazy-prereq'Libravatar Junio C Hamano1-3/+3
A test prerequisite defined by various test scripts with slightly different semantics has been consolidated into a single copy and made into a lazily defined one. * wc/make-funnynames-shared-lazy-prereq: t: factor out FUNNYNAMES as shared lazy prereq
2018-08-06t: factor out FUNNYNAMES as shared lazy prereqLibravatar William Chargin1-3/+3
A fair number of tests need to check that the filesystem supports file names including "funny" characters, like newline, tab, and double-quote. Jonathan Nieder suggested that this be extracted into a lazy prereq in the top-level `test-lib.sh`. This patch effects that change. The FUNNYNAMES prereq now uniformly requires support for newlines, tabs, and double-quotes in filenames. This very slightly decreases the power of some tests, which might have run previously on a system that supports (e.g.) newlines and tabs but not double-quotes, but now will not. This seems to me like an acceptable tradeoff for consistency. One test (`t/t9902-completion.sh`) defined FUNNYNAMES to further require the separators \034 through \037, the test for which was implemented using the Bash-specific $'\034' syntax. I've elected to leave this one as is, renaming it to FUNNIERNAMES. After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has only one result. Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t9000-t9999: fix broken &&-chainsLibravatar Eric Sunshine1-2/+2
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-28Merge branch 'nd/completion-negation'Libravatar Junio C Hamano1-2/+39
Continuing with the idea to programmatically enumerate various pieces of data required for command line completion, the codebase has been taught to enumerate options prefixed with "--no-" to negate them. * nd/completion-negation: completion: collapse extra --no-.. options completion: suppress some -no- options parse-options: option to let --git-completion-helper show negative form
2018-06-11completion: collapse extra --no-.. optionsLibravatar Nguyễn Thái Ngọc Duy1-11/+38
The commands that make use of --git-completion-helper feature could now produce a lot of --no-xxx options that a command can take. This in many case could nearly double the amount of completable options, using more screen estate and also harder to search for the wanted option. This patch attempts to mitigate that by collapsing extra --no- options, the ones that are added by --git-completion-helper and not in original struct option arrays. The "--no-..." option will be displayed in this case to hint about more options, e.g. > ~/w/git $ git clone -- --bare --origin= --branch= --progress --checkout --quiet --config= --recurse-submodules --depth= --reference= --dissociate --reference-if-able= --filter= --separate-git-dir= --hardlinks --shallow-exclude= --ipv4 --shallow-since= --ipv6 --shallow-submodules --jobs= --shared --local --single-branch --mirror --tags --no-... --template= --no-checkout --upload-pack= --no-hardlinks --verbose --no-tags and when you complete it with --no-<tab>, all negative options will be presented: > ~/w/git $ git clone --no- --no-bare --no-quiet --no-branch --no-recurse-submodules --no-checkout --no-reference --no-config --no-reference-if-able --no-depth --no-separate-git-dir --no-dissociate --no-shallow-exclude --no-filter --no-shallow-since --no-hardlinks --no-shallow-submodules --no-ipv4 --no-shared --no-ipv6 --no-single-branch --no-jobs --no-tags --no-local --no-template --no-mirror --no-upload-pack --no-origin --no-verbose --no-progress Corner case: to make sure that people will never accidentally complete the fake option "--no-..." there must be one real --no- in the first complete listing even if it's not from the original struct option. PS. This could could be made simpler with ";&" to fall through from "--no-*" block and share the code but ";&" is not available on bash-3 (i.e. Mac) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01Merge branch 'cc/tests-without-assuming-ref-files-backend'Libravatar Junio C Hamano1-1/+1
Quite a many tests assumed that newly created refs are made as loose refs using the files backend, which have been updated to use proper plumbing like rev-parse and update-ref, to avoid breakage once we start using different ref backends. * cc/tests-without-assuming-ref-files-backend: t990X: use '.git/objects' as 'deep inside .git' path t: make many tests depend less on the refs being files
2018-06-01Merge branch 'nd/command-list'Libravatar Junio C Hamano1-20/+3
The list of commands with their various attributes were spread across a few places in the build procedure, but it now is getting a bit more consolidated to allow more automation. * nd/command-list: completion: allow to customize the completable command list completion: add and use --list-cmds=alias completion: add and use --list-cmds=nohelpers Move declaration for alias.c to alias.h completion: reduce completable command list completion: let git provide the completable command list command-list.txt: documentation and guide line help: use command-list.txt for the source of guides help: add "-a --verbose" to list all commands with synopsis git: support --list-cmds=list-<category> completion: implement and use --list-cmds=main,others git --list-cmds: collect command list in a string_list git.c: convert --list-* to --list-cmds=* Remove common-cmds.h help: use command-list.h for common command list generate-cmds.sh: export all commands to command-list.h generate-cmds.sh: factor out synopsis extract code
2018-05-30t990X: use '.git/objects' as 'deep inside .git' pathLibravatar Christian Couder1-1/+1
Tests t9902-completion.sh and t9903-bash-prompt.sh each have tests that check what happens when we are "in the '.git' directory" and when we are "deep inside the '.git' directory". To test the case when we are "deep inside the '.git' directory" the test scripts used to perform a `cd .git/refs/heads`. As there are plans to implement other ref storage systems, let's use '.git/objects' instead of '.git/refs/heads' as the "deep inside the '.git' directory" path. This makes it clear to readers that these tests do not depend on which ref backend is used. The internals of the loose refs backend are still tested in t1400-update-ref.sh. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-29completion: suppress some -no- optionsLibravatar Nguyễn Thái Ngọc Duy1-2/+0
Most --no- options do have some use, even if rarely to negate some option that's specified in an alias. These options --no-ours and --no-theirs however have no clear semantics. If I specify "--ours --no-theirs", the second will reset writeout stage and is equivalent of "--no-ours --no-theirs" which is not that easy to see. Drop them. You can either switch from --ours to --theirs and back but you can never negate them. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-29parse-options: option to let --git-completion-helper show negative formLibravatar Nguyễn Thái Ngọc Duy1-2/+14
When 7fb6aefd2a (Merge branch 'nd/parseopt-completion' - 2018-03-14) is merged, the completion for negative form is left out because the series is alread long and it could be done in a follow up series. This is it. --git-completion-helper now provides --no-xxx so that git-completion.bash can drop the extra custom --no-xxx in the script. It adds a lot more --no-xxx than what's current provided by the git-completion.bash script. We'll trim that down later. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21completion: add and use --list-cmds=aliasLibravatar Nguyễn Thái Ngọc Duy1-18/+0
By providing aliases via --list-cmds=, we could simplify command collection code in the script. We only issue one git command. Before this patch that is "git config", after it's "git --list-cmds=". In "git help" completion case we actually reduce one "git" process (for getting guides) but that call was added in this series so it does not really count. A couple of bash functions are removed because they are not needed anymore. __git_compute_all_commands() and $__git_all_commands stay because they are still needed for completing pager.* config and without "alias" group, the result is still cacheable. There is a slight (good) change in _git_help() with this patch: before "git help <tab>" shows external commands (as in _not_ part of git) as well as part of $__git_all_commands. We have finer control over command listing now and can exclude that because we can't provide a man page for external commands anyway. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21completion: let git provide the completable command listLibravatar Nguyễn Thái Ngọc Duy1-2/+3
Instead of maintaining a separate list of command classification, which often could go out of date, let's centralize the information back in git. While the function in git-completion.bash implies "list porcelain commands", that's not exactly what it does. It gets all commands (aka --list-cmds=main,others) then exclude certain non-porcelain ones. We could almost recreate this list two lists list-mainporcelain and others. The non-porcelain-but-included-anyway is added by the third category list-complete. Note that the current completion script incorrectly classifies filter-branch as porcelain and t9902 tests this behavior. We keep it this way in t9902 because this test does not really care which particular command is porcelain or plumbing, they're just names. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21t9902-completion: exercise __git_complete_index_file() directlyLibravatar SZEDER Gábor1-107/+118
The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17completion: improve handling quoted paths in 'git ls-files's outputLibravatar SZEDER Gábor1-2/+15
If any pathname contains backslash, double quote, tab, newline, or any control characters, 'git ls-files' and 'git diff-index' will enclose that pathname in double quotes and escape those special characters using C-style one-character escape sequences or \nnn octal values. This prevents those files from being listed during git-aware path completion, because due to the quoting they will never match the current word to be completed. Extend __git_index_files()'s 'awk' script to remove all that quoting and escaping from unique path components, so even paths containing (almost all) such special characters can be completed. Paths containing newline characters are still an issue, though. We use newlines as separator character when filling the COMPREPLY array, so a path with one or more newline will end up split to two or more elements in COMPREPLY, basically breaking completion. There is nothing we can do about it without a significant performance hit, so let's just ignore such paths for now. As far as paths with newlines are concerned, this isn't any different from the previous behavior, because those paths were always omitted, though in the past they were omitted because due to the quoting they didn't match the current word to be completed. Anyway, Bash's own filename completion (Meta-/) can complete even those paths, if need be. Note: - We don't dequote path components right away as they are coming in, because then we would have to dequote each directory name repeatedly, as many times as it appears in the input, i.e. as many times as the number of listed paths it contains. Instead, we dequote them at the end, as we print unique path components. - Even when a directory name itself does not contain any special characters, it will still be quoted if any of its trailing path components do. If a directory contains paths both with and without special characters, then the name of that directory will appear both quoted and unquoted in the output of 'git ls-files' and 'git diff-index'. Consequently, we will add such a directory name to the deduplicating associative array twice: once quoted and once unquoted. This means that we have to be careful after dequoting a directory name, and only print it if we haven't seen the same directory name unquoted. - It would be wonderful if we could just pass '-z' to those git commands to output \0-separated unquoted paths, and use \0 as record separator in the 'awk' script processing their output... this patch would be so much simpler, almost trivial even. Unfortunately, however, POSIX and most 'awk' implementations don't support \0 as record separator (GNU awk does support it). - This patch makes the earlier change to list paths with 'core.quotePath=false' basically redundant, because this could decode any \nnn-escaped non-ASCII character just fine, as well. However, I suspect that 'git ls-files' can deal with those non-ASCII characters faster than this updated 'awk' script; just in case someone is burdened with tons of pathnames containing non-ASCII characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17t9902-completion: ignore COMPREPLY element order in some testsLibravatar SZEDER Gábor1-2/+4
The order or possible completion words in the COMPREPLY array doesn't actually matter, as long as all the right words are in there, because Bash will sort them anyway. Yet, our tests looking at the elements of COMPREPLY always expect them to be in a specific order. Now, this hasn't been an issue before, but the next patch is about to optimize a bit more our git-aware path completion, and as a harmless side effect the order of elements in COMPREPLY will change. Worse, the order will be downright undefined, because after the next patch path components will come directly from iterating through an associative array in 'awk', and the order of iteration over the elements in those arrays is undefined, and indeed different 'awk' implementations produce different order. Consequently, we can't get away with simply adjusting the expected results in the affected tests. Modify the 'test_completion' helper function to sort both the expected and the actual results, i.e. the elements in COMPREPLY, before comparing them, so the tests using this helper function will work regardless of the order of elements. Note that this change still leaves a bunch of tests depending on the order of elements in COMPREPLY, tests that focus on a specific helper function and therefore don't use the 'test_completion' helper. I would rather deal with those later, when (if ever) the need actually arises, than create unnecessary code churn now. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17completion: let 'ls-files' and 'diff-index' filter matching pathsLibravatar SZEDER Gábor1-0/+1
During git-aware path completion, e.g. 'git rm dir/fil<TAB>', both 'git ls-files' and 'git diff-index' list all paths in the given 'dir/' matching certain criteria (cached, modified, untracked, etc.) appropriate for the given git command, even paths whose names don't begin with 'fil'. This comes with a considerable performance penalty when the directory in question contains a lot of paths, but the current word can be uniquely completed or when only a handful of those paths match the current word. Reduce the number of iterations in this codepath from the number of paths to the number of matching paths by specifying an appropriate globbing pattern to 'git ls-files' and 'git diff-index' to list only paths that match the current word to be completed. Note that both commands treat backslashes as escape characters in their file arguments, e.g. to preserve the literal meaning of globbing characters, so we have to double every backslash in the globbing pattern. This is why one of the path completion tests specifically checks the completion of a path containing a literal backslash character (that test still fails, though, because both commands output such paths enclosed in double quotes and the special characters escaped; a later patch in this series will deal with those). This speeds up path completion considerably when there are a lot of non-matching paths to be filtered out. Uniquely completing a tracked filename at the top of the worktree in linux.git (over 62k files), i.e. what's doing all the hard work behind 'git rm Mak<TAB>' to complete 'Makefile': Before this patch, best of five, on Linux: $ time cur=Mak __git_complete_index_file real 0m2.159s user 0m1.299s sys 0m1.089s After: real 0m0.033s user 0m0.023s sys 0m0.015s Difference: -98.5% Speedup: 65.4x Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17completion: improve handling quoted paths on the command lineLibravatar SZEDER Gábor1-2/+44
Our git-aware path completion doesn't work when it has to complete a word already containing quoted and/or backslash-escaped characters on the command line. The root cause of the issue is that completion functions see all words on the command line verbatim, i.e. including all backslash, single and double quote characters that the shell would eventually remove when executing the finished command. These quoting/escaping characters cause different issues depending on which path component of the word to be completed contains them: - The quoting/escaping is in the prefix path component(s). Let's suppose we have a directory called 'New Dir', containing two untracked files 'file.c' and 'file.o', and we have a gitignore rule ignoring object files. In this case all of these: git add New\ Dir/<TAB> git add "New Dir/<TAB> git add 'New Dir/<TAB> should uniquely complete 'file.c' right away, but Bash offers both 'file.c' and 'file.o' instead. The reason for this behavior is that our completion script uses the prefix directory name like 'git -C "New\ Dir/" ls-files ...", i.e. with the backslash inside double quotes. Git then tries to enter a directory called 'New\ Dir', which (most likely) fails because such a directory doesn't exists. As a result our completion script doesn't list any files, leaves the COMPREPLY array empty, which in turn causes Bash to fall back to its simple filename completion and lists all files in that directory, i.e. both 'file.c' and 'file.o'. - The quoting/escaping is in the path component to be completed. Let's suppose we have two untracked files 'New File.c' and 'New File.o', and we have a gitignore rule ignoring object files. In this case all of these: git add New\ Fi<TAB> git add "New Fi<TAB> git add 'New Fi<TAB> should uniquely complete 'New File.c' right away, but Bash offers both 'New File.c' and 'New File.o' instead. The reason for this behavior is that our completion script uses this 'New\ Fi' or '"New Fi' etc. word to filter matching paths, and of course none of the potential filenames will match because of the included backslash or double quote. The end result is the same as above: the completion script doesn't list any files, Bash falls back to its filename completion, which then lists the matching object file as well. Add the new helper function __git_dequote() [1], which removes (most of[2]) the quoting and escaping from the word it gets as argument. To minimize the overhead of calling this function, store its result in the variable $dequoted_word, supposed to be declared local in the caller; simply printing the result would require a command substitution imposing the overhead of fork()ing a subshell. Use this function in __git_complete_index_file() to dequote the current word, i.e. the path, to be completed, to avoid the above described quoting-related issues, thereby fixing two of the failing quoted path completion tests. [1] The bash-completion project already has a dequote() function, which I hoped I could borrow to deal with this, but unfortunately it doesn't work quite well for this purpose (perhaps that's why even the bash-completion project only rarely uses it). The main issue is that their dequote() is implemented as: eval printf %s "$1" 2> /dev/null where $1 would contain the word to be completed. While it's a short and sweet one-liner, the use of 'eval' requires that $1 is a syntactically valid string, which is not the case when quoting the path like 'git add "New Dir/<TAB>'. This causes 'eval' to fail, because it can't find the matching closing double quote, and the function returns nothing. The result is totally broken behavior, as if the current word were empty, and the completion script would then list all files from the current directory. This is why one of the quoted path completion tests specifically checks the completion of a path with an opening but without a corresponding closing double quote character. Furthermore, the 'eval' performs all kinds of expansions, which may or may not be desired; I think it's the latter. Finally, using this function would require a command substitution. [2] Bash understands the $'string' quoting as well, which "expands to 'string', with backslash-escaped characters replaced as specified by the ANSI C standard" (quoted from Bash manpage). Since shell metacharacters, field separators, globbing, etc. can all be easily entered using standard shell escaping or quoting, this type of quoting comes in handly when dealing with control characters that are otherwise difficult both to "type" and to see on the command line. Because of this difficulty I would assume that people do avoid pathnames with such control characters anyway, so I didn't bother implementing it. This function is already way too long as it is. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17completion: support completing non-ASCII pathnamesLibravatar SZEDER Gábor1-1/+1
Unless the user has 'core.quotePath=false' somewhere in the configuration, both 'git ls-files' and 'git diff-index' will by default quote any pathnames that contain bytes with values higher than 0x80, and escape those bytes as '\nnn' octal values. This prevents completing paths when the current path component to be completed contains any non-ASCII, most notably UTF-8, characters, because none of the listed quoted paths will match the current word on the command line. Set 'core.quotePath=false' for those 'git ls-files' and 'git diff-index' invocations, so they won't consider bytes higher than 0x80 as "unusual", and won't quote pathnames containing such characters. Note that pathnames containing backslash, double quote, or control characters will still be quoted; a later patch in this series will deal with those. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17t9902-completion: add tests demonstrating issues with quoted pathnamesLibravatar SZEDER Gábor1-0/+91
Completion functions see all words on the command line verbatim, including any backslash-escapes, single and double quotes that might be there. Furthermore, git commands quote pathnames if they contain certain special characters. All these create various issues when doing git-aware path completion. Add a couple of failing tests to demonstrate these issues. Later patches in this series will discuss these issues in detail as they fix them. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-25completion: add --option completion for most builtin commandsLibravatar Nguyễn Thái Ngọc Duy1-0/+6
Many builtin commands use parseopt which can expose the option list via --git-completion-helper but do not have explicit support in git-completion.bash. This patch detects those commands and uses __gitcomp_builtin for option completion. This does not pollute the command name completion though. "git <tab>" will show you the same set as before. This only kicks in when you type the correct command name. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>