summaryrefslogtreecommitdiff
path: root/contrib/completion/git-completion.bash
AgeCommit message (Collapse)AuthorFilesLines
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-11git-completion.bash: silence "not a valid object" errorsLibravatar Dylan Smith1-1/+1
Trying to complete the command git show master:./file would cause a "Not a valid object name" error to be output on standard error. Silence the error so it won't appear on the command line. Signed-off-by: Dylan Smith <dylan.ah.smith@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-15completion: complete refs for "git commit -c"Libravatar Jeff King1-0/+7
The "-c" and "-C" options take an existing commit, so let's complete refs, just as we would for --squash or --fixup. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29completion: fix warning for zshLibravatar Felipe Contreras1-0/+2
Otherwise the user might get something like: git-completion.sh:2466: command not found: compdef If this script is loaded before compinit. The script would work either way, but let's not be more annoying to the user. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28Merge branch 'maint'Libravatar Junio C Hamano1-0/+2
2012-11-28Merge branch 'fc/zsh-completion'Libravatar Junio C Hamano1-43/+61
* fc/zsh-completion: completion: start moving to the new zsh completion completion: add new zsh completion
2012-11-28completion: add options --single-branch and --branch to "git clone"Libravatar Ralf Thielow1-0/+2
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-25Merge branch 'sg/complete-help-undup'Libravatar Junio C Hamano1-1/+1
* sg/complete-help-undup: completion: remove 'help' duplicate from porcelain commands
2012-11-25Sync with 1.8.0.1Libravatar Junio C Hamano1-1/+1
2012-11-24Completion must sort before using uniqLibravatar Marc Khouzam1-1/+1
The user can be presented with invalid completion results when trying to complete a 'git checkout' command. This can happen when using a branch name prefix that matches multiple remote branches. For example, if available branches are: master remotes/GitHub/maint remotes/GitHub/master remotes/origin/maint remotes/origin/master When performing completion on 'git checkout ma' the user will be given the choices: maint master However, 'git checkout maint' will fail in this case, although completion previously said 'maint' was valid. Furthermore, when performing completion on 'git checkout mai', no choices will be suggested. So, the user is first told that the branch name 'maint' is valid, but when trying to complete 'mai' into 'maint', that completion is no longer valid. The completion results should never propose 'maint' as a valid branch name, since 'git checkout' will refuse it. The reason for this bug is that the uniq program only works with sorted input. The man page states "uniq prints the unique lines in a sorted file". When __git_refs uses the guess heuristic employed by checkout for tracking branches it wants to consider remote branches but only if the branch name is unique. To do that, it calls 'uniq -u'. However the input given to 'uniq -u' is not sorted. Therefore, in the above example, when dealing with 'git checkout ma', "__git_refs '' 1" will find the following list: master maint master maint master which, when passed to 'uniq -u' will remain the same. Therefore 'maint' will be wrongly suggested as a valid option. When dealing with 'git checkout mai', the list will be: maint maint which happens to be sorted and will be emptied by 'uniq -u', properly ignoring 'maint'. A solution for preventing the completion script from suggesting such invalid branch names is to first call 'sort' and then 'uniq -u'. Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-19completion: start moving to the new zsh completionLibravatar Felipe Contreras1-43/+61
Zsh's bash completion emulation is buggy, not properly maintained, and we have some workarounds in place for different bugs that appeared in various versions. Since I'm the only one that has worked on that code lately[1], it might make snese to use the code I wrote specifically for git. The advantages are: 1) Less workarounds * No need to hack __get_comp_words_by_ref * No need to hack IFS or words 2) Improved features * 'git show master' now properly adds a space at the end (IFS bug) * 'git checkout --conflict=' now properly returns the sub-items (missing feature) 3) Consolidated code * It's all now in a single chunk, and it's basically the same as git-completion.zsh Since there's some interest in moving the zsh-specific code out of this script, lets go ahead and warn the users that they should be using git-completion.zsh. [1] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=history;f=Completion/bashcompinit Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-14completion: remove 'help' duplicate from porcelain commandsLibravatar SZEDER Gábor1-1/+1
The list of all git commands is computed from the output of 'git help -a', which already includes 'help', so there is no need to explicitly add it once more when computing the list of porcelain commands. Note that 'help' wasn't actually offered twice because of this, because Bash filters duplicates from possible completion words. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-16completion: add format-patch options to send-emailLibravatar Felipe Contreras1-17/+18
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-25Merge branch 'maint'Libravatar Junio C Hamano1-8/+1
* maint: Revert "completion: fix shell expansion of items"
2012-09-25Revert "completion: fix shell expansion of items"Libravatar Jeff King1-8/+1
This reverts commit 25ae7cfd19c8f21721363c64163cd5d9d1135b20. That patch does fix expansion of weird variables in some simple tests, but it also seems to break other things, like expansion of refs by "git checkout". While we're sorting out the correct solution, we are much better with the original bug (people with metacharacters in their completions occasionally see an error message) than the current bug (ref completion does not work at all). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Merge branch 'maint'Libravatar Junio C Hamano1-1/+8
* maint: Documentation: Document signature showing options completion: fix shell expansion of items
2012-09-20Merge branch 'nd/maint-remote-remove' into maintLibravatar Junio C Hamano1-2/+2
* nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'
2012-09-20completion: fix shell expansion of itemsLibravatar Felipe Contreras1-1/+8
As reported by Jeroen Meijer[1]; the current code doesn't deal properly with items (tags, branches, etc.) that have ${} in them because they get expaned by bash while using compgen. A simple solution is to quote the items so they get expanded properly (\$\{\}). In order to achieve that I took bash-completion's quote() function, which is rather simple, and renamed it to __git_quote() as per Jeff King's suggestion. Solves the original problem for me. [1] http://article.gmane.org/gmane.comp.version-control.git/201596 Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* maint: t/perf: add "trash directory" to .gitignore Add missing -z to git check-attr usage text for consistency with man page git-jump: ignore (custom) prefix in diff mode Documentation: indent-with-non-tab uses "equivalent tabs" not 8 completion: add --no-edit to git-commit
2012-09-16completion: add --no-edit to git-commitLibravatar Yacine Belkadi1-1/+2
Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'cn/branch-set-upstream-to'Libravatar Junio C Hamano1-1/+5
Finishing touches to the recently graduated topic to introduce "git branch --set-upstream-to" option. * cn/branch-set-upstream-to: completion: complete branch name for "branch --set-upstream-to=" completion: add --set-upstream-to and --unset-upstream
2012-09-12Merge branch 'nd/maint-remote-remove'Libravatar Junio C Hamano1-2/+2
* nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'
2012-09-11completion: complete branch name for "branch --set-upstream-to="Libravatar Michael J Gruber1-0/+3
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-11completion: add --set-upstream-to and --unset-upstreamLibravatar Carlos Martín Nieto1-1/+2
Remove --set-upstream as it's deprecated now. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06remote: prefer subcommand name 'remove' to 'rm'Libravatar Nguyễn Thái Ngọc Duy1-2/+2
All remote subcommands are spelled out words except 'rm'. 'rm', being a popular UNIX command name, may mislead users that there are also 'ls' or 'mv'. Use 'remove' to fit with the rest of subcommands. 'rm' is still supported and used in the test suite. It's just not widely advertised. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Merge branch 'da/difftool-updates'Libravatar Junio C Hamano1-1/+1
"git difftool --dir-diff" learned to use symbolic links to prepare temporary copy of the working tree when available. * da/difftool-updates: difftool: silence warning Add Code Compare v2.80.4 as a merge / diff tool for Windows mergetool,difftool: Document --tool-help consistently difftool: Disable --symlinks on cygwin difftool: Handle compare() returning -1 difftool: Wrap long lines for readability difftool: Check all return codes from compare() difftool: Handle finding mergetools/ in a path with spaces difftool: Use symlinks when diffing against the worktree difftool: Call the temp directory "git-difftool" difftool: Move option values into a hash difftool: Eliminate global variables difftool: Simplify print_tool_help()
2012-08-10Add Code Compare v2.80.4 as a merge / diff tool for WindowsLibravatar Sebastian Schuberth1-1/+1
Code Compare is a commercial file comparison tool for Windows, see http://www.devart.com/codecompare/ Version 2.80.4 added support for command line arguments preceded by a dash instead of a slash. This is required for Git for Windows because slashes in command line arguments get mangled with according to these rules: http://www.mingw.org/wiki/Posix_path_conversion Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-28Merge branch 'fc/git-prompt-script'Libravatar Junio C Hamano1-255/+7
Split a rather heavy-ish "git completion" script out to create a separate "git prompting" script, to help lazy-autoloading of the completion part while making prompting part always available.
2012-06-19completion: respect $GIT_DIRLibravatar SZEDER Gábor1-0/+3
The __gitdir() helper function finds out the path of the git repository by running 'git rev-parse --git-dir'. However, it has a shortcut first to avoid the overhead of running a git command in a subshell when the current directory is at the top of the work tree, i.e. when it contains a '.git' subdirectory. If the 'GIT_DIR' environment variable is set then it specifies the path to the git repository, and the autodetection of the '.git' directory is not necessary. However, $GIT_DIR is only taken into acocunt by 'git rev-parse --git-dir', and the check for the '.git' subdirectory is performed first, so it wins over the path given in $GIT_DIR. There are several completion (helper) functions that depend on __gitdir(), and when the above case triggers the completion script will do weird things, like offering refs, aliases, or stashes from a different repository, or displaying wrong or broken prompt, etc. So check first whether $GIT_DIR is set, and only proceed with checking the '.git' directory in the current directory if it isn't. 'git rev-parse' would also check whether the path in $GIT_DIR is a proper '.git' directory, i.e. 'HEAD', 'refs/', and 'objects/' are present and accessible, but we don't have to be that thorough for the bash prompt. And we've lived with an equally permissive check for '.git' in the current working directory for years anyway. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-13Merge branch 'fc/git-complete-helper-fix'Libravatar Junio C Hamano1-7/+7
* fc/git-complete-helper-fix: completion: put main git and gitk completion functions back into git namespace
2012-06-13completion: remove credential helpers from porcelain commandsLibravatar SZEDER Gábor1-0/+2
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-13completion: put main git and gitk completion functions back into git namespaceLibravatar SZEDER Gábor1-7/+7
Commit 7f02f3d7 (completion: rename internal helpers _git and _gitk, 2012-05-19) renamed said functions to _main_git() and _main_gitk(), respectively. By convention the name of our git-completion-specific functions start with '_git' or '__git' prefix, so rename those functions once again to put them back into our "namespace". Use the two underscore prefix, because _git_main() could be mistaken for the completion function of the (not yet existing) 'git main' command. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-10completion: warn people about duplicated functionLibravatar Junio C Hamano1-0/+2
The __gitdir function is duplicated between completion and prompt scripts, and these definitions should not diverge; otherwise one of them can be subtly broken depending on the order the user's shell dot-sources them. Leave a note to people who may want to touch one copy to make sure they update the other one in sync. Hopefully this line would also appear in the context of the patch to allow reviewers to notice a patch that attempts to update only one of them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25Merge branch 'fc/git-complete-helper-fix'Libravatar Junio C Hamano1-5/+17
Resurrects old behaviour of _git/_gitk for external users.
2012-05-22completion: split __git_ps1 into a separate scriptLibravatar Felipe Contreras1-255/+2
bash-completion 1.90 shipped with support to load completions dynamically[1], which means the git completion script wouldn't be loaded until the user types 'git <tab>'--this creates a problem to people using __git_ps1(); that function won't be available when the shell is first created. For now distributions have workarounded this issue by moving the git completion to the "compatdir"[2]; this of course is not ideal. The solution, proposed by Kerrick Staley[3], is to split the git script in two; the part that deals with __git_ps1() in one (i.e. git-prompt.sh), and everything else in another (i.e. git-completion.bash). Another benefit of this is that zsh user that are not interested in the bash completion can use it for their prompts, which has been tried before[4]. The only slight issue is that __gitdir() would be duplicated, but this is probably not a big deal. So let's go ahead and move __git_ps1() to a new file. While at this, I took the liberty to reformat the help text in the new file. [1] http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=99c4f7f25f50a7cb2fce86055bddfe389effa559 [2] http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/git&id=974380fabb8f9f412990b17063bf578d98c44a82 [3] http://mid.gmane.org/CANaWP3w9KDu57aHquRRYt8td_haSWTBKs7zUHy-xu0B61gmr9A@mail.gmail.com [4] http://mid.gmane.org/1303824288-15591-1-git-send-email-mstormo@gmail.com Cc: Kerrick Staley <mail@kerrickstaley.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Ville Skyttä <ville.skytta@iki.fi> Cc: Dan McGee <dan@archlinux.org> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-22completion: remove executable modeLibravatar Felipe Contreras1-0/+0
No reason to have it executable. Every way this script is intended to be used includes the 'source' command. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-20completion: add support for backwards compatibilityLibravatar Felipe Contreras1-0/+12
Some people might be relying on _git and _gitk to define custom aliases, unfortunately, commit 6b179ad (completion: add new __git_complete helper) broke that support. "bash: [: 1: unary operator expected" This can be easily fixed by using __git_complete, but it's not meant to be public. Although _git and _gitk are probably not meant to be public, it's easy to keep having support for them by having a wrapper to the proper new function that is fully functional. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-20completion: rename internal helpers _git and _gitkLibravatar Felipe Contreras1-5/+5
Would be useful to provide backwards compatibility for _git. Also, zsh completion uses _git, and it cannot be changed. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-17Merge branch 'fc/git-complete-helper'Libravatar Junio C Hamano1-37/+33
By Felipe Contreras * fc/git-complete-helper: completion: add new __git_complete helper
2012-05-14Merge branch 'fc/simplify-complete-revlist-file'Libravatar Junio C Hamano1-4/+2
By Felipe Contreras * fc/simplify-complete-revlist-file: completion: simplify __git_complete_revlist_file
2012-05-14completion: add new __git_complete helperLibravatar Felipe Contreras1-37/+33
This simplifies the completions, and would make it easier to define aliases in the future. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-07completion: simplify __git_complete_revlist_fileLibravatar Felipe Contreras1-4/+2
Use new __gitcomp_nl; this is the last place that uses COMPREPLY and compgen directly outside __gitcomp* functions. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-21completion: fix completion after 'git --option <TAB>'Libravatar SZEDER Gábor1-1/+2
The bash completion doesn't work when certain options to git itself are specified, e.g. 'git --no-pager <TAB>' errors out with error: invalid key: alias.--no-pager The main _git() completion function finds out the git command name by looping through all the words on the command line and searching for the first word that is not a known option for the git command. Unfortunately the list of known git options was not updated in a long time, and newer options are not skipped but mistaken for a git command. Such a misrecognized "command" is then passed to __git_aliased_command(), which in turn passes it to a 'git config' query, hence the error. Currently the following options are misrecognized for a git command: -c --no-pager --exec-path --html-path --man-path --info-path --no-replace-objects --work-tree= --namespace= To fix this we could just update the list of options to be skipped, but the same issue will likely arise, if the git command learns a new option in the future. Therefore, to make it more future proof against new options, this patch changes that loop to skip all option-looking words, i.e. words starting with a dash. We also have to handle the '-c' option specially, because it takes a configutation parameter in a separate word, which must be skipped, too. [fc: added tests] Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-21completion: avoid trailing space for --exec-pathLibravatar Jonathan Nieder1-0/+1
"--exec-path" looks to the completion script like an unambiguous successful completion, but it is wrong to emit a SP after it as if declaring that we are done with completion; the user could be trying to do git --exec-path; # print name of helper directory or git --exec-path=/path/to/alternative/helper/dir <subcommand> so the most helpful thing to do is to leave out the trailing space and leave it to the operator to type an equal sign or carriage return according to the situation. [fc: added tests] Cc: Andreas Schwab <schwab@linux-m68k.org> Reported-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-21completion: add missing general optionsLibravatar Felipe Contreras1-0/+2
And add relevant tests. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-21completion: simplify by using $prevLibravatar Felipe Contreras1-2/+2
cword-1 is the previous word ($prev). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-21completion: simplify __gitcomp_1Libravatar Felipe Contreras1-6/+6
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-23Merge branch 'am/completion-zsh-fix'Libravatar Junio C Hamano1-1/+2
* am/completion-zsh-fix: contrib/completion: "local var=()" is misinterpreted as func-decl by zsh
2012-03-21contrib/completion: "local var=()" is misinterpreted as func-decl by zshLibravatar Alex Merry1-1/+2
Certain versions of zsh seems to treat local var=() as a function declaration, rather than an assignment of an empty array, although its documentation does not suggest that this should be the case. With zsh 4.3.15 on Fedora Core 15, this causes __git_ps1 " (%s)" to trigger an error message: local:2: command not found: svn_url_pattern when GIT_PS1_SHOWUPSTREAM="auto". Signed-off-by: Alex Merry <dev@randomguy3.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-06Merge branch 'zj/diff-stat-dyncol'Libravatar Junio C Hamano1-0/+1
By Zbigniew Jędrzejewski-Szmek (8) and Junio C Hamano (1) * zj/diff-stat-dyncol: : This breaks tests. Perhaps it is not worth using the decimal-width stuff : for this series, at least initially. diff --stat: add config option to limit graph width diff --stat: enable limiting of the graph part diff --stat: add a test for output with COLUMNS=40 diff --stat: use a maximum of 5/8 for the filename part merge --stat: use the full terminal width log --stat: use the full terminal width show --stat: use the full terminal width diff --stat: use the full terminal width diff --stat: tests for long filenames and big change counts
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 23:05:22 +0000