summaryrefslogtreecommitdiff
path: root/contrib/completion/git-completion.bash
AgeCommit message (Collapse)AuthorFilesLines
2013-06-14Merge branch 'rr/complete-difftool-fixup'Libravatar Junio C Hamano1-2/+2
"git difftool" can take both revs to be compared and pathspecs. "git show" takes revs, revs:path and pathspecs. * rr/complete-difftool-fixup: completion: show can take both revlist and paths completion: difftool takes both revs and files
2013-06-11Merge branch 'fc/completion-less-ls-remote'Libravatar Junio C Hamano1-8/+2
* fc/completion-less-ls-remote: completion: avoid ls-remote in certain scenarios
2013-06-09completion: show can take both revlist and pathsLibravatar Ramkumar Ramachandra1-1/+1
The 'git show' completion uses __git_complete_file (aliased to __git_complete_revlist_file), because accepts <tree-ish>:<path> as well as <commit-ish>. But the command also accepts range of commits in A..B notation, so using __git_complete_revlist_file is more appropriate. There still remain two users of __git_complete_file, completions for "archive" and "ls-tree". As these commands do not take range notation, and "git show" no longer uses __git_complete_file, the implementation of it can be updated not to complete ranges, but that is a separate topic. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-03completion: difftool takes both revs and filesLibravatar Ramkumar Ramachandra1-1/+1
'git difftool' is clearly a frontend to 'git diff' and is used in exactly the same way, but it uses a misleadingly named completion function __git_complete_file. It happens to work only because it calls __git_complete_revlist_file that completes both revs and paths. Change it to use __git_complete_revlist_file, just like 'git diff'. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02completion: avoid ls-remote in certain scenariosLibravatar Felipe Contreras1-8/+2
It's _very_ slow in many cases, and there's really no point in fetching *everything* from the remote just for completion. In many cases it might be faster for the user to type the whole thing. If the user manually specifies 'refs/*', then the full ls-remote completion is triggered. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02Merge branch 'fc/completion'Libravatar Junio C Hamano1-115/+30
* fc/completion: completion: remove __git_index_file_list_filter() completion: add space after completed filename completion: add hack to enable file mode in bash < 4 completion: refactor __git_complete_index_file() completion: refactor diff_index wrappers completion: use __gitcompadd for __gitcomp_file completion; remove unuseful comments completion: document tilde expansion failure in tests completion: add file completion tests
2013-06-02Merge branch 'fc/zsh-leftover-bits'Libravatar Junio C Hamano1-15/+7
* fc/zsh-leftover-bits: completion: zsh: improve bash script loading completion: synchronize zsh wrapper completion: cleanup zsh wrapper
2013-05-21completion: regression fix for zshLibravatar Felipe Contreras1-1/+1
zsh completion wrapper doesn't reimplement __gitcompadd(). Although it should be trivial to do that, let's use __gitcomp_nl() which achieves exactly the same thing, specially since the suffix ($4) has to be empty. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-09git-svn: added an --include-path flagLibravatar Paul Walmsley1-1/+1
The SVN::Fetcher module is now able to filter for inclusion as well as exclusion (as used by --ignore-path). Also added tests, documentation changes and git completion script. If you have an SVN repository with many top level directories and you only want a git-svn clone of some of them then using --ignore-path is difficult as it requires a very long regexp. In this case it's much easier to filter for inclusion. [ew: remove trailing whitespace] Signed-off-by: Paul Walmsley <pjwhams@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-08completion: synchronize zsh wrapperLibravatar Felipe Contreras1-2/+2
So it's closer to the full zsh wrapper. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08completion: cleanup zsh wrapperLibravatar Felipe Contreras1-13/+5
There's no need for a separate function; we can call 'emulate -k ksh func'. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-29git-completion.bash: add remote.pushdefault to config listLibravatar Ramkumar Ramachandra1-0/+5
224c2171 (remote.c: introduce remote.pushdefault, 2013-04-02) introduced the remote.pushdefault configuration variable, but forgot to teach git-completion.bash about it. Fix this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-29git-completion.bash: add branch.*.pushremote to config listLibravatar Ramkumar Ramachandra1-2/+2
9f765ce (remote.c: introduce branch.<name>.pushremote, 2013-04-02) introduced the configuration variable branch.*.pushremote, but forgot to teach git-completion.bash about it. Fix this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-29Merge branch 'maint'Libravatar Junio C Hamano1-1/+10
* maint: complete: zsh: use zsh completion for the main cmd complete: zsh: trivial simplification git-completion.bash: complete branch.*.rebase as boolean git-completion.bash: add diff.submodule to config list git-completion.bash: lexical sorting for diff.statGraphWidth
2013-04-29git-completion.bash: complete branch.*.rebase as booleanLibravatar Ramkumar Ramachandra1-0/+4
6fac1b83 (completion: add missing config variables, 2009-06-29) added "rebase" to the list of completions for "branch.*.*", but forgot to specify completions for the values that this configuration variable can take (namely "false" and "true"). Fix this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-29git-completion.bash: add diff.submodule to config listLibravatar Ramkumar Ramachandra1-0/+5
c47ef57 (diff: introduce diff.submodule configuration variable, 2012-11-13) introduced the diff.submodule configuration variable, but forgot to teach git-completion.bash about it. Fix this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-29git-completion.bash: lexical sorting for diff.statGraphWidthLibravatar Ramkumar Ramachandra1-1/+1
df44483a (diff --stat: add config option to limit graph width, 2012-03-01) added the option diff.startGraphWidth to the list of configuration variables in git-completion.bash, but failed to notice that the list is sorted alphabetically. Move it to its rightful place in the list. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: add missing format-patch optionsLibravatar Felipe Contreras1-1/+2
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: remove __git_index_file_list_filter()Libravatar Felipe Contreras1-20/+8
Refactor the code into the only caller; __git_index_files(). Also, Somehow messing up with the 'path' variable messes up the 'PATH' variable. So let's not do that. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: add space after completed filenameLibravatar Felipe Contreras1-1/+1
Just like before fea16b4 (git-completion.bash: add support for path completion). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: add hack to enable file mode in bash < 4Libravatar Felipe Contreras1-36/+7
This way we don't need all the compat stuff, different filters, and so on. Also, now we complete exactly the same in bash 3 and bash 4. This is the way bash-completion did it for quite some time, when bash 3 was supported. For more information about the hack: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272660#64 Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: refactor __git_complete_index_file()Libravatar Felipe Contreras1-6/+3
The calls to __gitcomp_file() are essentially the same, but with different prefix. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: refactor diff_index wrappersLibravatar Felipe Contreras1-55/+16
At the end of the day what we really need is to find out the files that have been staged, or modified, because those files are the ones that make sense to pass as arguments to 'git commit'. We need diff-index to find those out, since 'git ls-files' doesn't do that. But we don't need wrappers and wrappers basically identical to the ones used for 'git ls-files', when we can pretend it receives a --committable option that would return what we need. That way, we can remove a bunch of code without any functional changes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion: use __gitcompadd for __gitcomp_fileLibravatar Felipe Contreras1-1/+1
Like the rest of the script does; let's not access COMPREPLY directly. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27completion; remove unuseful commentsLibravatar Felipe Contreras1-2/+0
The only caller, __git_complete_index_file() doesn't specify any limits to the options for 'git ls-files', neither should this function. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24Sync with maintLibravatar Junio C Hamano1-7/+0
* maint: Update draft release notes to 1.8.2.2 completion: remove duplicate block for "git commit -c" cherry-pick/revert: make usage say '<commit-ish>...'
2013-04-24completion: remove duplicate block for "git commit -c"Libravatar Mårten Kongstad1-7/+0
Remove one of two consecutive, identical blocks for "git commit -c". This was caused by a mechanical mismerge at d931e2fb252e (Merge branch 'mp/complete-paths', 2013-02-08). The side branch wanted to add this block at fea16b47 but the same fix was done independently at 685397585 already. Signed-off-by: Mårten Kongstad <marten.kongstad@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-14completion: small optimizationLibravatar Felipe Contreras1-4/+4
No need to calculate a new $c with a space if we are not going to do anything it with it. There should be no functional changes, except that a word "foo " with no suffixes can't be matched. But $cur cannot have a space at the end anyway. So it's safe. Based on the code from SZEDER Gábor. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-14completion: inline __gitcomp_1 to its sole callsiteLibravatar Felipe Contreras1-15/+11
There is no point in calling a separate function that is only used in one place. Especially considering that there's no need to call compgen, and we traverse the words ourselves both in __gitcompadd, and __gitcomp_1. Let's squash the functions together, and traverse only once. This improves performance. For N number of words: == 1 == original: 0.002s new: 0.000s == 10 == original: 0.005s new: 0.001s == 100 == original: 0.009s new: 0.006s == 1000 == original: 0.027s new: 0.019s == 10000 == original: 0.163s new: 0.151s == 100000 == original: 1.555s new: 1.497s No functional changes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-14completion: get rid of compgenLibravatar Felipe Contreras1-5/+10
The functionality we use from compgen is not much, we can do the same manually, with drastic improvements in speed, especially when dealing with only a few words. This patch also has the sideffect that brekage reported by Jeroen Meijer and SZEDER Gábor gets fixed because we no longer expand the resulting words. Here are some numbers filtering N amount of words: == 1 == original: 0.002s new: 0.000s == 10 == original: 0.002s new: 0.000s == 100 == original: 0.003s new: 0.002s == 1000 == original: 0.012s new: 0.011s == 10000 == original: 0.056s new: 0.066s == 100000 == original: 2.669s new: 0.622s If the results are not narrowed: == 1 == original: 0.002s new: 0.000s == 10 == original: 0.002s new: 0.001s == 100 == original: 0.004s new: 0.004s == 1000 == original: 0.020s new: 0.015s == 10000 == original: 0.101s new: 0.355s == 100000 == original: 2.850s new: 31.941s So, unless 'git checkout <tab>' usually gives you more than 10000 results, you'll get an improvement :) Other possible solutions perform better after 1000 words, but worst if less than that: COMPREPLY=($(awk -v cur="$3" -v pre="$2" -v suf="$4" '$0 ~ cur { print pre$0suf }' <<< "$1" )) COMPREPLY=($(printf -- "$2%s$4\n" $1 | grep "^$2$3")) Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-14completion: add new __gitcompadd helperLibravatar Felipe Contreras1-5/+8
The idea is to never touch the COMPREPLY variable directly. This allows other completion systems (i.e. zsh) to override __gitcompadd, and do something different instead. Also, this allows further optimizations down the line. There should be no functional changes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12completion: get rid of empty COMPREPLY assignmentsLibravatar Felipe Contreras1-21/+0
There's no functional reason for those, the only purpose they are supposed to serve is to say "we don't provide any words here", but even for that it's not used consistently. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12completion: add more cherry-pick optionsLibravatar Felipe Contreras1-1/+6
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano1-1/+1
There was no Porcelain way to say "I no longer am interested in this submodule", once you express your interest in a submodule with "submodule init". "submodule deinit" is the way to do so. * jl/submodule-deinit: submodule: add 'deinit' command
2013-03-11Merge branch 'mp/complete-paths'Libravatar Junio C Hamano1-5/+11
* mp/complete-paths: git-completion.bash: zsh does not implement function redirection correctly
2013-03-11git-completion.bash: zsh does not implement function redirection correctlyLibravatar Matthieu Moy1-5/+11
A recent change added functions whose entire standard error stream is redirected to /dev/null using a construct that is valid POSIX.1 but is not widely used: funcname () { cd "$1" && run some command "$2" } 2>/dev/null Even though this file is "git-completion.bash", zsh completion support dot-sources it (instead of asking bash to grok it like tcsh completion does), and zsh does not implement this redirection correctly. With zsh, trying to complete an inexistant directory gave this: git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory: no-such-dir/ Also these functions use "cd" to first go somewhere else before running a command, but the location the caller wants them to go that is given as an argument to them should not be affected by CDPATH variable the users may have set for their interactive session. To fix both of these, wrap the body of the function in a subshell, unset CDPATH at the beginning of the subshell, and redirect the standard error stream of the subshell to /dev/null. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-04submodule: add 'deinit' commandLibravatar Jens Lehmann1-1/+1
With "git submodule init" the user is able to tell git he cares about one or more submodules and wants to have it populated on the next call to "git submodule update". But currently there is no easy way he could tell git he does not care about a submodule anymore and wants to get rid of his local work tree (except he knows a lot about submodule internals and removes the "submodule.$name.url" setting from .git/config together with the work tree himself). Help those users by providing a 'deinit' command. This removes the whole submodule.<name> section from .git/config (either for the given submodule(s) or for all those which have been initialized if '.' is used) together with their work tree. Fail if the current work tree contains modifications (unless forced), but don't complain when either the work tree is already removed or no settings are found in .git/config. Add tests and link the man pages of "git submodule deinit" and "git rm" to assist the user in deciding whether removing or unregistering the submodule is the right thing to do for him. Also add the deinit subcommand to the completion list. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-17Merge branch 'mp/diff-algo-config'Libravatar Junio C Hamano1-1/+13
Add diff.algorithm configuration so that the user does not type "diff --histogram". * mp/diff-algo-config: diff: Introduce --diff-algorithm command line option config: Introduce diff.algorithm variable git-completion.bash: Autocomplete --minimal and --histogram for git-diff
2013-02-12completion: support 'git config --local'Libravatar Matthieu Moy1-2/+2
This needs to be done in two places: __git_config_get_set_variables to allow clever completion of "git config --local --get foo<tab>", and _git_config to allow "git config --loc<tab>" to complete to --local. While we're there, change the order of options in the code to match git-config.txt. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-08Merge branch 'mp/complete-paths'Libravatar Junio C Hamano1-15/+240
The completion script used to let the default completer to suggest pathnames, which gave too many irrelevant choices (e.g. "git add" would not want to add an unmodified path). Teach it to use a more git-aware logic to enumerate only relevant ones. * mp/complete-paths: git-completion.bash: add support for path completion
2013-02-01Merge branch 'jc/do-not-let-random-file-interfere-with-completion-tests'Libravatar Junio C Hamano1-1/+10
Scripts to test bash completion was inherently flaky as it was affected by whatever random things the user may have on $PATH. * jc/do-not-let-random-file-interfere-with-completion-tests: t9902: protect test from stray build artifacts
2013-01-28Merge branch 'bc/fix-array-syntax-for-3.0-in-completion-bash'Libravatar Junio C Hamano1-1/+1
Fix use of an array notation that older versions of bash do not understand. * bc/fix-array-syntax-for-3.0-in-completion-bash: git-completion.bash: replace zsh notation that breaks bash 3.X
2013-01-24t9902: protect test from stray build artifactsLibravatar Junio C Hamano1-1/+10
When you have random build artifacts in your build directory, left behind by running "make" while on another branch, the "git help -a" command run by __git_list_all_commands in the completion script that is being tested does not have a way to know that they are not part of the subcommands this build will ship. Such extra subcommands may come from the user's $PATH. They will interfere with the tests that expect a certain prefix to uniquely expand to a known completion. Instrument the completion script and give it a way for us to tell what (subset of) subcommands we are going to ship. Also add a test to "git --help <prefix><TAB>" expansion. It needs to show not just commands but some selected documentation pages. Based on an idea by Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-0/+1
Add a new command "git check-ignore" for debugging .gitignore files. The variable names may want to get cleaned up but that can be done in-tree. * as/check-ignore: clean.c, ls-files.c: respect encapsulation of exclude_list_groups t0008: avoid brace expansion add git-check-ignore sub-command setup.c: document get_pathspec() add.c: extract new die_if_path_beyond_symlink() for reuse add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse pathspec.c: rename newly public functions for clarity add.c: move pathspec matchers into new pathspec.c for reuse add.c: remove unused argument from validate_pathspec() dir.c: improve docs for match_pathspec() and match_pathspec_depth() dir.c: provide clear_directory() for reclaiming dir_struct memory dir.c: keep track of where patterns came from dir.c: use a single struct exclude_list per source of excludes Conflicts: builtin/ls-files.c dir.c
2013-01-18git-completion.bash: replace zsh notation that breaks bash 3.XLibravatar Brandon Casey1-1/+1
When commit d8b45314 began separating the zsh completion from the bash completion, it introduced a zsh completion "bridge" section into the bash completion script for zsh users to use until they migrated to the zsh script. The zsh '+=()' append-to-array notation prevents bash 3.00.15 on CentOS 4.x from loading the completion script and breaks test 9902. We can easily work around this by using standard Bash array notation. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-18Merge branch 'ds/completion-silence-in-tree-path-probe'Libravatar Junio C Hamano1-1/+1
An internal ls-tree call made by completion code only to probe if a path exists in the tree recorded in a commit object leaked error messages when the path is not there. It is not an error at all and should not be shown to the end user. * ds/completion-silence-in-tree-path-probe: git-completion.bash: silence "not a valid object" errors
2013-01-16diff: Introduce --diff-algorithm command line optionLibravatar Michal Privoznik1-0/+11
Since command line options have higher priority than config file variables and taking previous commit into account, we need a way how to specify myers algorithm on command line. However, inventing `--myers` is not the right answer. We need far more general option, and that is `--diff-algorithm`. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-16config: Introduce diff.algorithm variableLibravatar Michal Privoznik1-0/+1
Some users or projects prefer different algorithms over others, e.g. patience over myers or similar. However, specifying appropriate argument every time diff is to be used is impractical. Moreover, creating an alias doesn't play nicely with other tools based on diff (git-show for instance). Hence, a configuration variable which is able to set specific algorithm is needed. For now, these four values are accepted: 'myers' (which has the same effect as not setting the config variable at all), 'minimal', 'patience' and 'histogram'. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-14git-completion.bash: Autocomplete --minimal and --histogram for git-diffLibravatar Michal Privoznik1-1/+1
Even though --patience was already there, we missed --minimal and --histogram for some reason. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-11git-completion.bash: add support for path completionLibravatar Manlio Perillo1-15/+240
The git-completion.bash script did not implemented full, git aware, support to complete paths, for git commands that operate on files within the current working directory or the index. As an example: git add <TAB> will suggest all files in the current working directory, including ignored files and files that have not been modified. Support path completion, for git commands where the non-option arguments always refer to paths within the current working directory or the index, as follows: * the path completion for the "git rm" and "git ls-files" commands will suggest all cached files. * the path completion for the "git add" command will suggest all untracked and modified files. Ignored files are excluded. * the path completion for the "git clean" command will suggest all untracked files. Ignored files are excluded. * the path completion for the "git mv" command will suggest all cached files when expanding the first argument, and all untracked and cached files for subsequent arguments. In the latter case, empty directories are included and ignored files are excluded. * the path completion for the "git commit" command will suggest all files that have been modified from the HEAD, if HEAD exists, otherwise it will suggest all cached files. For all affected commands, completion will always stop at directory boundary. Only standard ignored files are excluded, using the --exclude-standard option of the ls-files command. When using a recent Bash version, Git path completion will be the same as builtin file completion, e.g. git add contrib/ will suggest relative file names. Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>