summaryrefslogtreecommitdiff
path: root/contrib/completion/git-completion.bash
AgeCommit message (Collapse)AuthorFilesLines
2018-01-26completion: fix completing merge strategies on non-C localesLibravatar Duy Nguyen1-1/+1
The anchor string "Available strategies are:" is translatable so __git_list_merge_strategies may fail to collect available strategies from 'git merge' on non-C locales. Force C locale on this command. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06Merge branch 'ac/complete-pull-autostash'Libravatar Junio C Hamano1-0/+1
The shell completion (in contrib/) learned that "git pull" can take the "--autostash" option. * ac/complete-pull-autostash: completion: add --autostash and --no-autostash to pull
2017-11-27Merge branch 'tz/complete-branch-copy'Libravatar Junio C Hamano1-1/+1
Command line completion (in contrib/) has been taught about the "--copy" option of "git branch". * tz/complete-branch-copy: completion: add '--copy' option to 'git branch'
2017-11-27Merge branch 'rv/sendemail-tocmd-in-config-and-completion'Libravatar Junio C Hamano1-0/+1
Teach "sendemail.tocmd" to places that know about "sendemail.to", like documentation and shell completion (in contrib/). * rv/sendemail-tocmd-in-config-and-completion: completion: add git config sendemail.tocmd Documentation/config: add sendemail.tocmd to list preceding "See git-send-email(1)"
2017-11-27Merge branch 'jc/ignore-cr-at-eol'Libravatar Junio C Hamano1-1/+1
The "diff" family of commands learned to ignore differences in carriage return at the end of line. * jc/ignore-cr-at-eol: diff: --ignore-cr-at-eol xdiff: reassign xpparm_t.flags bits
2017-11-22completion: add --autostash and --no-autostash to pullLibravatar Albert Astals Cid1-0/+1
Ideally we should only autocomplete if pull has --rebase since they only work with it but could not figure out how to do that and the error message of doing git pull --autostash points out that you need --rebase so i guess it's good enough Signed-off-by: Albert Astals Cid <albert.astals.cid@kdab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-17completion: add '--copy' option to 'git branch'Libravatar Todd Zullinger1-1/+1
In 52d59cc645 (branch: add a --copy (-c) option to go with --move (-m), 2017-06-18), `git branch` learned a `--copy` option. Include it when providing command completions. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15Merge branch 'tz/fsf-address-update'Libravatar Junio C Hamano1-2/+1
* tz/fsf-address-update: Replace Free Software Foundation address in license notices Replace Free Software Foundation address in license notices
2017-11-14completion: add git config sendemail.tocmdLibravatar Rasmus Villemoes1-0/+1
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-09Replace Free Software Foundation address in license noticesLibravatar Todd Zullinger1-2/+1
The mailing address for the FSF has changed over the years. Rather than updating the address across all files, refer readers to gnu.org, as the GNU GPL documentation now suggests for license notices. The mailing address is retained in the full license files (COPYING and LGPL-2.1). The old address is still present in t/diff-lib/COPYING. This is intentional, as the file is used in tests and the contents are not expected to change. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-08diff: --ignore-cr-at-eolLibravatar Junio C Hamano1-1/+1
A new option --ignore-cr-at-eol tells the diff machinery to treat a carriage-return at the end of a (complete) line as if it does not exist. Just like other "--ignore-*" options to ignore various kinds of whitespace differences, this will help reviewing the real changes you made without getting distracted by spurious CRLF<->LF conversion made by your editor program. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> [jch: squashed in command line completion by Dscho] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06Merge branch 'tb/complete-checkout'Libravatar Junio C Hamano1-1/+2
Command line completion (in contrib/) update. * tb/complete-checkout: completion: add remaining flags to checkout
2017-11-06Merge branch 'dm/run-command-ignored-hook-advise'Libravatar Junio C Hamano1-0/+1
A hook script that is set unexecutable is simply ignored. Git notifies when such a file is ignored, unless the message is squelched via advice.ignoredHook configuration. * dm/run-command-ignored-hook-advise: run-command: add hint when a hook is ignored
2017-10-25completion: add remaining flags to checkoutLibravatar Thomas Braun1-1/+2
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-10-10run-command: add hint when a hook is ignoredLibravatar Damien Marié1-0/+1
When an hook is present but the file is not set as executable then git will ignore the hook. For now this is silent which can be confusing. This commit adds this warning to improve the situation: hint: The 'pre-commit' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false` To allow the old use-case of enabling/disabling hooks via the executable flag a new setting is introduced: advice.ignoredHook. Signed-off-by: Damien Marié <damien@dam.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07completion: add --broken and --dirty to describeLibravatar Thomas Braun1-1/+1
When the flags for broken and dirty were implemented in b0176ce6b5 (builtin/describe: introduce --broken flag, 2017-03-21) and 9f67d2e827 (Teach "git describe" --dirty option, 2009-10-21) the completion was not updated, although these flags are useful completions. Add them. Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-06Merge branch 'xz/send-email-batch-size'Libravatar Junio C Hamano1-0/+2
"git send-email" learned to overcome some SMTP server limitation that does not allow many pieces of e-mails to be sent over a single session. * xz/send-email-batch-size: send-email: --batch-size to work around some SMTP server limit
2017-07-05send-email: --batch-size to work around some SMTP server limitLibravatar xiaoqiang zhao1-0/+2
Some email servers (e.g. smtp.163.com) limit the number emails to be sent per session (connection) and this will lead to a faliure when sending many messages. Teach send-email to disconnect after sending a number of messages (configurable via the --batch-size=<num> option), wait for a few seconds (configurable via the --relogin-delay=<seconds> option) and reconnect, to work around such a limit. Also add two configuration variables to give these options the default. Note: We will use this as a band-aid for now, but in the longer term, we should look at and react to the SMTP error code from the server; Xianqiang reports that 450 and 451 are returned by problematic servers. cf. https://public-inbox.org/git/7993e188.d18d.15c3560bcaf.Coremail.zxq_yx_007@163.com/ Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-13Merge branch 'rf/completion'Libravatar Junio C Hamano1-1/+28
Completion updates. * rf/completion: completion: add git config credentialCache.ignoreSIGHUP completion: add git config credential completions completion: add git config advice completions completion: add git config am.threeWay completion completion: add git config core completions completion: add git config gc completions
2017-06-13Merge branch 'rf/completion-config-commit' into maintLibravatar Junio C Hamano1-0/+3
Completion update. * rf/completion-config-commit: completion: add completions for git config commit
2017-06-04Merge branch 'tg/stash-push-fixup' into maintLibravatar Junio C Hamano1-1/+4
The shell completion script (in contrib/) learned "git stash" has a new "push" subcommand. * tg/stash-push-fixup: completion: add git stash push
2017-06-04Merge branch 'rf/completion-config-commit'Libravatar Junio C Hamano1-0/+3
Completion update. * rf/completion-config-commit: completion: add completions for git config commit
2017-06-02completion: add git config credentialCache.ignoreSIGHUPLibravatar Rikard Falkeborn1-0/+1
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02completion: add git config credential completionsLibravatar Rikard Falkeborn1-0/+3
Add missing completions for git config credential: * credential.helper * credential.useHttpPath * credential.username Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02completion: add git config advice completionsLibravatar Rikard Falkeborn1-1/+9
Add missing completions for git config advice: * advice.amWorkDir * advice.pushAlreadyExists * advice.pushFetchFirst * advice.pushNeedsForce * advice.pushNonFFCurrent * advice.pushNonFFMatching * advice.pushUpdateRejected * advice.rmHints * advice.statusUoption Remove completion for git config advice.pushNonFastForward, since it was renamed to pushUpdateRejected in 1184564eac8e. The config still works, but is no longer part of the documentation. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02completion: add git config am.threeWay completionLibravatar Rikard Falkeborn1-0/+1
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02completion: add git config core completionsLibravatar Rikard Falkeborn1-0/+10
Add missing completions for git config core: * core.checkStat * core.commentChar * core.hideDotFiles * core.hooksPath * core.packedRefsTimeout * core.precomposeUnicode * core.protectHFS * core.protectNTFS * core.splitIndex * core.sshCommand Note that some configs are only used for some platforms (hideDotFiles on Windows and precomposeUnicode on Mac). Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02completion: add git config gc completionsLibravatar Rikard Falkeborn1-0/+4
Add missing completion for git config gc options: * gc.aggressiveDepth * gc.autoDetach * gc.logExpiry * gc.worktreePruneExpire Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-30completion: add completions for git config commitLibravatar Rikard Falkeborn1-0/+3
Add missing completions for git config: * commit.cleanup * commit.gpgSign * commit.verbose Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29Merge branch 'tg/stash-push-fixup'Libravatar Junio C Hamano1-1/+4
The shell completion script (in contrib/) learned "git stash" has a new "push" subcommand. * tg/stash-push-fixup: completion: add git stash push
2017-05-17completion: add git stash pushLibravatar Thomas Gummerer1-1/+4
When introducing git stash push in f5727e26e4 ("stash: introduce push verb", 2017-02-19), I forgot to add it to the completion code. Add it now. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-16Merge branch 'ab/clone-no-tags'Libravatar Junio C Hamano1-0/+1
"git clone" learned the "--no-tags" option not to fetch all tags initially, and also set up the tagopt not to follow any tags in subsequent fetches. * ab/clone-no-tags: tests: rename a test having to do with shallow submodules clone: add a --no-tags option to clone without tags tests: change "cd ... && git fetch" to "cd &&\n\tgit fetch"
2017-05-16Merge branch 'sk/status-short-branch-color-config'Libravatar Junio C Hamano1-0/+2
The colors in which "git status --short --branch" showed the names of the current branch and its remote-tracking branch are now configurable. * sk/status-short-branch-color-config: status: add color config slots for branch info in "--short --branch" status: fix missing newline when comment chars are disabled
2017-05-01Merge branch 'jk/complete-checkout-sans-dwim-remote'Libravatar Junio C Hamano1-1/+10
Completion for "git checkout <branch>" that auto-creates the branch out of a remote tracking branch can now be disabled, as this completion often gets in the way when completing to checkout an existing local branch that happens to share the same prefix with bunch of remote tracking branches. * jk/complete-checkout-sans-dwim-remote: completion: optionally disable checkout DWIM
2017-05-01clone: add a --no-tags option to clone without tagsLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Add a --no-tags option to clone without fetching any tags. Without this change there's no easy way to clone a repository without also fetching its tags. When supplying --single-branch the primary remote branch will be cloned, but in addition tags will be followed & retrieved. Now --no-tags can be added --single-branch to clone a repository without tags, and which only tracks a single upstream branch. This option works without --single-branch as well, and will do a normal clone but not fetch any tags. Many git commands pay some fixed overhead as a function of the number of references. E.g. creating ~40k tags in linux.git will cause a command like `git log -1 >/dev/null` to run in over a second instead of in a matter of milliseconds, in addition numerous other things will slow down, e.g. "git log <TAB>" with the bash completion will slowly show ~40k references instead of 1. The user might want to avoid all of that overhead to simply use a repository like that to browse the "master" branch, or something like a CI tool might want to keep that one branch up-to-date without caring about any other references. Without this change the only way of accomplishing this was either by manually tweaking the config in a fresh repository: git init git && cat >git/.git/config <<EOF && [remote "origin"] url = git@github.com:git/git.git tagOpt = --no-tags fetch = +refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master EOF cd git && git pull Which requires hardcoding the "master" name, which may not be the main --single-branch would have retrieved, or alternatively by setting tagOpt=--no-tags right after cloning & deleting any existing tags: git clone --single-branch git@github.com:git/git.git && cd git && git config remote.origin.tagOpt --no-tags && git tag -l | xargs git tag -d Which of course was also subtly buggy if --branch was pointed at a tag, leaving the user in a detached head: git clone --single-branch --branch v2.12.0 git@github.com:git/git.git && cd git && git config remote.origin.tagOpt --no-tags && git tag -l | xargs git tag -d Now all this complexity becomes the much simpler: git clone --single-branch --no-tags git@github.com:git/git.git Or in the case of cloning a single tag "branch": git clone --single-branch --branch v2.12.0 --no-tags git@github.com:git/git.git Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-28status: add color config slots for branch info in "--short --branch"Libravatar Stephen Kent1-0/+2
Add color config slots to be used in the status short-format when displaying local and remote tracking branch information. [jc: rebased on top of Peff's fix to 'git status' and tweaked the test to check both local and remote-tracking branch output] Signed-off-by: Stephen Kent <smkent@smkent.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-23completion: optionally disable checkout DWIMLibravatar Jeff King1-1/+10
When we complete branch names for "git checkout", we also complete remote branch names that could trigger the DWIM behavior. Depending on your workflow and project, this can be either convenient or annoying. For instance, my clone of gitster.git contains 74 local "jk/*" branches, but origin contains another 147. When I want to checkout a local branch but can't quite remember the name, tab completion shows me 251 entries. And worse, for a topic that has been picked up for pu, the upstream branch name is likely to be similar to mine, leading to a high probability that I pick the wrong one and accidentally create a new branch. This patch adds a way for the user to tell the completion code not to include DWIM suggestions for checkout. This can already be done by typing: git checkout --no-guess jk/<TAB> but that's rather cumbersome. The downside, of course, is that you no longer get completion support when you _do_ want to invoke the DWIM behavior. But depending on your workflow, that may not be a big loss (for instance, in git.git I am much more likely to want to detach, so I'd type "git checkout origin/jk/<TAB>" anyway). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> 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/+1
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-04-11Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano1-2/+2
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-03-30Merge branch 'sg/completion-ctags'Libravatar Junio C Hamano1-6/+66
Command line completion updates. * sg/completion-ctags: completion: offer ctags symbol names for 'git log -S', '-G' and '-L:' completion: extract completing ctags symbol names into helper function completion: put matching ctags symbol names directly into COMPREPLY
2017-03-30Merge branch 'sg/completion-refs-speedup'Libravatar Junio C Hamano1-71/+181
The refs completion for large number of refs has been sped up, partly by giving up disambiguating ambiguous refs and partly by eliminating most of the shell processing between 'git for-each-ref' and 'ls-remote' and Bash's completion facility. * sg/completion-refs-speedup: completion: speed up branch and tag completion completion: fill COMPREPLY directly when completing fetch refspecs completion: fill COMPREPLY directly when completing refs completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery completion: let 'for-each-ref' strip the remote name from remote branches completion: let 'for-each-ref' and 'ls-remote' filter matching refs completion: don't disambiguate short refs completion: don't disambiguate tags and branches completion: support excluding full refs completion: support completing fully qualified non-fast-forward refspecs completion: support completing full refs after '--option=refs/<TAB>' completion: wrap __git_refs() for better option parsing completion: remove redundant __gitcomp_nl() options from _git_commit()
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: offer ctags symbol names for 'git log -S', '-G' and '-L:'Libravatar SZEDER Gábor1-0/+28
Just like in the case of search patterns for 'git grep', see 29eec71f2 (completion: match ctags symbol names in grep patterns, 2011-10-21)), a common thing to look for using 'git log -S', '-G' and '-L:' is the name of a symbol. Teach the completion for 'git log' to offer ctags symbol names after these options, both in stuck and in unstuck forms. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: extract completing ctags symbol names into helper functionLibravatar SZEDER Gábor1-4/+29
The previous commit doubled the number of __git_match_ctag()'s positional parameters, and, to keep the position of existing parameters for the sake of backwards compatibility, the prefix, current word and suffix parameters ended up in different order than in other functions accepting the same parameters. Then there is a condition checking the existence of the tag file before invoking this function. We could still live with this if there were only a single callsite, but the next commit will add a few more, so it's worth providing a cleaner interface. Add the wrapper function __git_complete_symbol(), which encompasses the condition for checking the presence of the tag file and filling COMPREPLY, and accepts '--opt=val'-style options with default values that keep callsites simpler. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: put matching ctags symbol names directly into COMPREPLYLibravatar SZEDER Gábor1-3/+10
The one-liner awk script in __git_match_ctag() listing ctags symbol names for 'git grep <TAB>' is already smart enough to list only symbol names matching the current word to be completed. Extend this helper function to accept prefix and suffix parameters to be prepended and appended, respectively, to each listed symbol name in the awk script, so its output won't require any additional processing or filtering in the completion script before being handed over to Bash. Use the faster __gitcomp_direct() helper instead of __gitcomp_nl() to fill the fully processed matching symbol names into Bash's COMPREPLY array. Right after 'git grep <TAB>' in current git.git with 14k+ symbol names in the tag file, best of five: Before: $ time __gitcomp_nl "$(__git_match_ctag "" tags)" real 0m0.178s user 0m0.176s sys 0m0.000s After: $ time __gitcomp_direct "$(__git_match_ctag "" tags "" " ")" real 0m0.058s user 0m0.048s sys 0m0.008s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23completion: speed up branch and tag completionLibravatar SZEDER Gábor1-6/+19
Modify __git_heads() and __git_tags() and the few callsites they have, so we can let 'git for-each-ref' do all the hard work and these functions' output won't need any further processing or filtering before being handed over to Bash, resulting in faster branch and tag completion. These are some of the same tricks used in the previous commits to speed up refs completion, namely: - Extend both functions to accept prefix, current word and suffix positional parameters, all optional and all empty by default to keep the parameterless behavior unaltered. - Specify appropriate globbing patterns to 'git for-each-ref' to list only branches or tags matching the given current word parameter. - Modify the 'git for-each-ref --format=<...>' to include the given prefix and suffix. - Adjust all callsites to specify the proper prefix, current word and suffix parameters, and to fill COMPREPLY using __gitcomp_direct(). Signed-off-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 fetch refspecsLibravatar SZEDER Gábor1-3/+3
The __git_complete_fetch_refspecs() has to iterate over __git_refs()'s output anyway to turn the listed matching refs into refspecs, and it knows about the prefix and suffix that has to be added to each refspec. Modify this function to add the prefix and suffix to each refspec while iterating and feed the result, since it doesn't need further processing, to the new __gitcomp_direct() helper added in the previous commit, because it should be faster when there are a lot of refspecs to list. Signed-off-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-14/+40
__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' sort remote branches for 'checkout' DWIMeryLibravatar SZEDER Gábor1-1/+2
When listing unique remote branches for 'git checkout's tracking DWIMery, __git_refs() runs the classic '... |sort |uniq -u' pattern to filter out duplicate remote branches. Let 'git for-each-ref' do the sorting, sparing the overhead of fork()+exec()ing 'sort' and a stage in the pipeline where potentially relatively large amount of data can be passed between two subsequent pipeline stages. This speeds up refs completion for 'git checkout' a bit when a lot of remote branches match the current word to be completed. Listing a single local and 100k remote branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --track real 0m1.856s user 0m1.816s sys 0m0.060s After: real 0m1.550s user 0m1.512s sys 0m0.060s On Windows, before: real 0m3.128s user 0m2.155s sys 0m0.183s After: real 0m2.781s user 0m1.826s sys 0m0.136s 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' filter remote branches for 'checkout' DWIMeryLibravatar SZEDER Gábor1-9/+3
The code listing unique remote branches for 'git checkout's tracking DWIMery outputs only remote branches that match the current word to be completed, but the filtering is done in a shell loop iterating over all remote refs. Let 'git for-each-ref' do the filtering, as it can do so much more efficiently and we can remove that shell loop entirely. This speeds up refs completion for 'git checkout' considerably when there are a lot of non-matching remote refs to be filtered out. Uniquely completing a branch in a repository with 100k remote branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste --track real 0m1.993s user 0m1.740s sys 0m0.304s After: real 0m0.266s user 0m0.248s sys 0m0.012s On Windows, before: real 0m6.187s user 0m3.358s sys 0m2.121s After: real 0m0.750s user 0m0.015s sys 0m0.090s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>