summaryrefslogtreecommitdiff
path: root/contrib/completion
AgeCommit message (Collapse)AuthorFilesLines
2012-02-12Merge branch 'fc/zsh-completion'Libravatar Junio C Hamano1-56/+11
* fc/zsh-completion: completion: simplify __gitcomp and __gitcomp_nl implementations completion: use ls -1 instead of rolling a loop to do that ourselves completion: work around zsh option propagation bug
2012-02-07Merge branch 'rt/completion-branch-edit-desc'Libravatar Junio C Hamano1-1/+1
* rt/completion-branch-edit-desc: completion: --edit-description option for git-branch
2012-02-06completion: simplify __gitcomp and __gitcomp_nl implementationsLibravatar Felipe Contreras1-16/+3
These shell functions are written in an unnecessarily verbose way; simplify their "conditionally use $<number> after checking $# against <number>" logic by using shell's built-in conditional substitution facilities. Also remove the first of the two assignments to IFS in __gitcomp_nl that does not have any effect. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06completion: use ls -1 instead of rolling a loop to do that ourselvesLibravatar Felipe Contreras1-37/+2
This simplifies the code a great deal. In particular, it allows us to get rid of __git_shopt, which is used only in this fuction to enable 'nullglob' in zsh. [jn: squashed with a patch that actually gets rid of __git_shopt] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06completion: work around zsh option propagation bugLibravatar Felipe Contreras1-3/+6
When listing commands in zsh (git <TAB><TAB>), all of them will show up, instead of only porcelain ones. The root cause of this is because zsh versions from 4.3.0 to present (4.3.15) do not correctly propagate the SH_WORD_SPLIT option into the subshell in ${foo:=$(bar)} expressions. Because of this bug, the list of all commands was treated as a single word in __git_list_porcelain_commands and did not match any of the patterns that would usually cause plumbing to be excluded. With problematic versions of zsh, after running emulate sh fn () { var='one two' for v in $var; do echo $v; done } x=$(fn) : ${y=$(fn)} printing "$x" results in two lines as expected, but printing "$y" results in a single line because $var is expanded as a single word when evaluating fn to compute y. So avoid the construct, and use an explicit 'test -n "$foo" || foo=$(bar)' instead. [jn: clarified commit message, indentation style fix] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-30completion: --edit and --no-edit for git-mergeLibravatar Adrian Weimann1-1/+1
Signed-off-by: Adrian Weimann <adrian.weimann@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-29completion: --edit-description option for git-branchLibravatar Ralf Thielow1-1/+1
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-26git-completion: workaround zsh COMPREPLY bugLibravatar Felipe Contreras1-0/+8
zsh adds a backslash (foo\ ) for each item in the COMPREPLY array if IFS doesn't contain spaces. This issue has been reported[1], but there is no solution yet. This wasn't a problem due to another bug[2], which was fixed in zsh version 4.3.12. After this change, 'git checkout ma<tab>' would resolve to 'git checkout master\ '. Aditionally, the introduction of __gitcomp_nl in commit a31e626 (completion: optimize refs completion) in git also made the problem apparent, as Matthieu Moy reported. The simplest and most generic solution is to hide all the changes we do to IFS, so that "foo \nbar " is recognized by zsh as "foo bar". This works on versions of git before and after the introduction of __gitcomp_nl (a31e626), and versions of zsh before and after 4.3.12. Once zsh is fixed, we should conditionally disable this workaround to have the same benefits as bash users. [1] http://www.zsh.org/mla/workers/2012/msg00053.html [2] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=2e25dfb8fd38dbef0a306282ffab1d343ce3ad8d Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-21bash completion: use read -r everywhereLibravatar Thomas Rast1-6/+6
We use the 'read' command without -r, so that it treats '\' as an escape character, in several places. This breaks the loop reading refnames from git-for-each-ref in __git_refs() if there are refnames such as "foo'bar", in which case for-each-ref helpfully quotes them as $ git update-ref "refs/remotes/test/foo'bar" HEAD $ git for-each-ref --shell --format="ref=%(refname:short)" "refs/remotes" ref='test/foo'\''bar' Interpolating the \' here will read "ref='test/foo'''bar'" instead, and eval then chokes on the unbalanced quotes. However, since none of the read loops _want_ to have backslashes interpolated, it's much safer to use read -r everywhere. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'sg/complete-refs'Libravatar Junio C Hamano1-91/+110
* sg/complete-refs: completion: remove broken dead code from __git_heads() and __git_tags() completion: fast initial completion for config 'remote.*.fetch' value completion: improve ls-remote output filtering in __git_refs_remotes() completion: query only refs/heads/ in __git_refs_remotes() completion: support full refs from remote repositories completion: improve ls-remote output filtering in __git_refs() completion: make refs completion consistent for local and remote repos completion: optimize refs completion completion: document __gitcomp() Conflicts: contrib/completion/git-completion.bash
2011-11-09Merge branch 'sn/complete-bash-wo-process-subst'Libravatar Junio C Hamano1-1/+1
* sn/complete-bash-wo-process-subst: completion: don't leak variable from the prompt into environment
2011-11-09completion: don't leak variable from the prompt into environmentLibravatar SZEDER Gábor1-1/+1
Commit e5b8eebc (completion: fix issue with process substitution not working on Git for Windows, 2011-10-26) introduced a new variable in __git_ps1_show_upstream(), but didn't declare it as local to prevent it from leaking into the environment. We may want to rewrite it like the following, but that can wait until the next cycle. while read key value do ... done <<-EOF $(git config -z --get-regexp ...) EOF Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-30Merge branch 'jk/git-tricks'Libravatar Junio C Hamano1-0/+13
* jk/git-tricks: completion: match ctags symbol names in grep patterns contrib: add git-jump script contrib: add diff highlight script
2011-10-26completion: fix issue with process substitution not working on Git for WindowsLibravatar Stefan Naewe1-1/+2
Git for Windows comes with a bash that doesn't support process substitution. It issues the following error when using git-completion.bash with GIT_PS1_SHOWUPSTREAM set: $ export GIT_PS1_SHOWUPSTREAM=1 sh.exe": cannot make pipe for process substitution: Function not implemented sh.exe": cannot make pipe for process substitution: Function not implemented sh.exe": <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n '): ambiguous redirect Replace the process substitution with a 'here string'. Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: remove broken dead code from __git_heads() and __git_tags()Libravatar SZEDER Gábor1-20/+2
__git_heads() was introduced in 5de40f5 (Teach bash about git-repo-config., 2006-11-27), and __git_tags() in 88e21dc (Teach bash about completing arguments for git-tag, 2007-08-31). As their name suggests, __git_heads() is supposed to list only branches, and __git_tags() only tags. Since their introduction both of these functions consist of two distinct parts. The first part gets branches or tags, respectively, from a local repositoty using 'git for-each-ref'. The second part queries a remote repository given as argument using 'git ls-remote'. These remote-querying parts are broken in both functions since their introduction, because they list both branches and tags from the remote repository. (The 'git ls-remote' query is not limited to list only heads or tags, respectively, and the for loop filtering the query results prints everything except dereferenced tags.) This breakage could be easily fixed by passing the '--heads' or '--tags' options or appropriate refs patterns to the 'git ls-remote' invocations. However, that no one noticed this breakage yet is probably not a coincidence: neither of these two functions were used to query a remote repository, the remote-querying parts were dead code already upon thier introduction and remained dead ever since. Since those parts of code are broken, are and were never used, stop the bit-rotting and remove them. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: fast initial completion for config 'remote.*.fetch' valueLibravatar SZEDER Gábor1-0/+4
Refspecs for branches in a remote repository start with 'refs/heads/', so completing those refspecs with 'git config remote.origin.fetch <TAB>' always offers 'refs/heads/' first, because that's the unique part of the possible refspecs. But it does so only after querying the remote with 'git ls-remote', which can take a while when the request goes through some slower network to a remote server. Don't waste the user's time and offer 'refs/heads/' right away for 'git config remote.origin.fetch <TAB>'. The reason for putting 'refs/heads/' directly into COMPREPLY instead of using __gitcomp() is to avoid __gitcomp() adding a trailing space. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: improve ls-remote output filtering in __git_refs_remotes()Libravatar SZEDER Gábor1-9/+4
This follows suit of a previous patch for __git_refs(): use a while-read loop and let bash's word splitting get rid of object names from 'git ls-remote's output. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: query only refs/heads/ in __git_refs_remotes()Libravatar SZEDER Gábor1-8/+5
__git_refs_remotes() is used to provide completion for refspecs to set 'remote.*.fetch' config variables for branches on the given remote. So it's really only interested in refs under 'refs/heads/', but it queries the remote for all its refs and then filters out all refs outside of 'refs/heads/'. Let 'git ls-remote' do the filtering. Also remove the unused $cmd variable from __git_refs_remotes(). Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: support full refs from remote repositoriesLibravatar SZEDER Gábor1-8/+21
When the __git_refs() completion helper function lists refs from a local repository, it usually lists the refs' short name, except when it needs to provide completion for words starting with refs, because in that case it lists full ref names, see 608efb87 (bash: complete full refs, 2008-11-28). Add the same functionality to the code path dealing with remote repositories, too. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: improve ls-remote output filtering in __git_refs()Libravatar SZEDER Gábor1-7/+7
The remote-handling part of __git_refs() has a nice for loop and state machine case statement to iterate over all words from the output of 'git ls-remote' to identify object names and ref names. Since each line in the output of 'git ls-remote' consists of an object name and a ref name, we can do more effective filtering by using a while-read loop and letting bash's word splitting take care of object names. This way the code is easier to understand and the loop will need only half the number of iterations than before. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: make refs completion consistent for local and remote reposLibravatar SZEDER Gábor1-4/+2
For a local repository the __git_refs() completion helper function lists refs under 'refs/(tags|heads|remotes)/', plus some special refs like HEAD and ORIG_HEAD. For a remote repository, however, it lists all refs. Fix this inconsistency by specifying refs filter patterns for 'git ls-remote' to only list refs under 'refs/(tags|heads|remotes)/'. For now this makes it impossible to complete refs outside of 'refs/(tags|heads|remotes)/' in a remote repository, but a followup patch will resurrect that. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: optimize refs completionLibravatar SZEDER Gábor1-45/+70
After a unique command or option is completed, in most cases it is a good thing to add a trailing a space, but sometimes it doesn't make sense, e.g. when the completed word is an option taking an argument ('--option=') or a configuration section ('core.'). Therefore the completion script uses the '-o nospace' option to prevent bash from automatically appending a space to unique completions, and it has the __gitcomp() function to add that trailing space only when necessary. See 72e5e989 (bash: Add space after unique command name is completed., 2007-02-04), 78d4d6a2 (bash: Support unique completion on git-config., 2007-02-04), and b3391775 (bash: Support unique completion when possible., 2007-02-04). __gitcomp() therefore iterates over all possible completion words it got as argument, and checks each word whether a trailing space is necessary or not. This is ok for commands, options, etc., i.e. when the number of words is relatively small, but can be noticeably slow for large number of refs. However, while options might or might not need that trailing space, refs are always handled uniformly and always get that trailing space (or a trailing '.' for 'git config branch.<head>.'). Since refs listed by __git_refs() & co. are separated by newline, this allows us some optimizations with 'compgen'. So, add a specialized variant of __gitcomp() that only deals with possible completion words separated by a newline and uniformly appends the trailing space to all words using 'compgen -S " "' (or any other suffix, if specified), so no iteration over all words is needed. But we need to fiddle with IFS, because the default IFS containing a space would cause the added space suffix to be stripped off when compgen's output is stored in the COMPREPLY array. Therefore we use only newline as IFS, hence the requirement for the newline-separated possible completion words. Convert all callsites of __gitcomp() where it's called with refs, i.e. when it gets the output of either __git_refs(), __git_heads(), __git_tags(), __git_refs2(), __git_refs_remotes(), or the odd 'git for-each-ref' somewhere in _git_config(). Also convert callsites where it gets other uniformly handled newline separated word lists, i.e. either remotes from __git_remotes(), names of set configuration variables from __git_config_get_set_variables(), stashes, or commands. Here are some timing results for dealing with 10000 refs. Before: $ refs="$(__git_refs ~/tmp/git/repo-with-10k-refs/)" $ time __gitcomp "$refs" real 0m1.134s user 0m1.060s sys 0m0.130s After: $ time __gitcomp_nl "$refs" real 0m0.373s user 0m0.360s sys 0m0.020s Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: document __gitcomp()Libravatar SZEDER Gábor1-2/+7
I always forget which argument is which, and got tired of figuring it out over and over again. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21completion: match ctags symbol names in grep patternsLibravatar Jeff King1-0/+13
A common thing to grep for is the name of a symbol. This patch teaches the completion for "git grep" to look in a 'tags' file, if present, to complete a pattern. For example, in git.git: $ make tags $ git grep get_sha1<Tab><Tab> get_sha1 get_sha1_oneline get_sha1_1 get_sha1_with_context get_sha1_basic get_sha1_with_context_1 get_sha1_hex get_sha1_with_mode get_sha1_hex_segment get_sha1_with_mode_1 get_sha1_mb Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-17Merge branch 'sg/completion'Libravatar Junio C Hamano1-18/+6
* sg/completion: completion: unite --format and --pretty for 'log' and 'show' completion: unite --reuse-message and --reedit-message for 'notes'
2011-10-17Merge branch 'tm/completion-push-set-upstream'Libravatar Junio C Hamano1-1/+1
* tm/completion-push-set-upstream: completion: push --set-upstream
2011-10-17Merge branch 'tm/completion-commit-fixup-squash'Libravatar Junio C Hamano1-7/+4
* tm/completion-commit-fixup-squash: completion: commit --fixup and --squash completion: unite --reuse-message and --reedit-message handling
2011-10-10completion: unite --format and --pretty for 'log' and 'show'Libravatar SZEDER Gábor1-14/+4
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10completion: unite --reuse-message and --reedit-message for 'notes'Libravatar SZEDER Gábor1-4/+2
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06completion: push --set-upstreamLibravatar Teemu Matilainen1-1/+1
Signed-off-by: Teemu Matilainen <teemu.matilainen@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06completion: commit --fixup and --squashLibravatar Teemu Matilainen1-2/+3
Signed-off-by: Teemu Matilainen <teemu.matilainen@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06completion: unite --reuse-message and --reedit-message handlingLibravatar Teemu Matilainen1-6/+2
Signed-off-by: Teemu Matilainen <teemu.matilainen@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-17Merge branch 'js/ref-namespaces'Libravatar Junio C Hamano1-1/+2
* js/ref-namespaces: ref namespaces: tests ref namespaces: documentation ref namespaces: Support remote repositories via upload-pack and receive-pack ref namespaces: infrastructure Fix prefix handling in ref iteration functions
2011-07-11ref namespaces: documentationLibravatar Josh Triplett1-1/+1
Document the namespace mechanism in a new gitnamespaces(7) page. Reference it from receive-pack and upload-pack. Document the new --namespace option and GIT_NAMESPACE environment variable in git(1), and reference gitnamespaces(7). Add a sample Apache configuration to http-backend(1) to support namespaced repositories, and reference gitnamespaces(7). Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Jamey Sharp <jamey@minilop.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06ref namespaces: infrastructureLibravatar Josh Triplett1-0/+1
Add support for dividing the refs of a single repository into multiple namespaces, each of which can have its own branches, tags, and HEAD. Git can expose each namespace as an independent repository to pull from and push to, while sharing the object store, and exposing all the refs to operations such as git-gc. Storing multiple repositories as namespaces of a single repository avoids storing duplicate copies of the same objects, such as when storing multiple branches of the same source. The alternates mechanism provides similar support for avoiding duplicates, but alternates do not prevent duplication between new objects added to the repositories without ongoing maintenance, while namespaces do. To specify a namespace, set the GIT_NAMESPACE environment variable to the namespace. For each ref namespace, git stores the corresponding refs in a directory under refs/namespaces/. For example, GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can also specify namespaces via the --namespace option to git. Note that namespaces which include a / will expand to a hierarchy of namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under refs/namespaces/foo/refs/namespaces/bar/. This makes paths in GIT_NAMESPACE behave hierarchically, so that cloning with GIT_NAMESPACE=foo/bar produces the same result as cloning with GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It also avoids ambiguity with strange namespace paths such as foo/refs/heads/, which could otherwise generate directory/file conflicts within the refs directory. Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE environment variable and --namespace option, and support iterating over refs in a namespace. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Jamey Sharp <jamey@minilop.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-26Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: completion: replace core.abbrevguard to core.abbrev
2011-06-24Merge branch 'maint-1.7.4' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.7.4: completion: replace core.abbrevguard to core.abbrev
2011-06-24completion: replace core.abbrevguard to core.abbrevLibravatar Namhyung Kim1-1/+1
The core.abbrevguard config variable had removed and now core.abbrev has been used instead. Teach it. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-30Merge branch 'mk/grep-pcre'Libravatar Junio C Hamano1-1/+2
* mk/grep-pcre: git-grep: Fix problems with recently added tests git-grep: Update tests (mainly for -P) Makefile: Pass USE_LIBPCRE down in GIT-BUILD-OPTIONS git-grep: update tests now regexp type is "last one wins" git-grep: do not die upon -F/-P when grep.extendedRegexp is set. git-grep: Bail out when -P is used with -F or -E grep: Add basic tests configure: Check for libpcre git-grep: Learn PCRE grep: Extract compile_regexp_failed() from compile_regexp() grep: Fix a typo in a comment grep: Put calls to fixmatch() and regmatch() into patmatch() contrib/completion: --line-number to git grep Documentation: Add --line-number to git-grep synopsis
2011-05-16Merge branch 'sg/completion-updates'Libravatar Junio C Hamano1-4/+16
* sg/completion-updates: Revert "completion: don't declare 'local words' to make zsh happy" git-completion: fix regression in zsh support completion: move private shopt shim for zsh to __git_ namespace completion: don't declare 'local words' to make zsh happy
2011-05-10Merge branch 'fc/completion-zsh' into sg/completion-updatesLibravatar Junio C Hamano1-0/+8
* fc/completion-zsh: git-completion: fix regression in zsh support
2011-05-10Revert "completion: don't declare 'local words' to make zsh happy"Libravatar Junio C Hamano1-6/+2
This reverts commit 3bee6a4733a1ff03b9cc659ea026c6dc17567d4d, as the fix that will be used by upstream zsh folks should make it unnecessary.
2011-05-10git-completion: fix regression in zsh supportLibravatar Felipe Contreras1-0/+8
The zsh support of git-completion script in contrib/ is broken for current versions of zsh, and does not notice when there's a subcommand. For example: "git log origi<TAB>" gives no completions because it would try to find a "git origi..." command. This will be fixed by zsh 4.3.12, but for now we can workaround it by backporting the same fix as zsh folks implemented. The problem started after commit v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work with bash v4), which introduced _get_comp_words_by_ref() that comes from bash-completion[1] scripts, and relies on the 'words' variable. However, it turns out 'words' is a special variable used by zsh completion. From zshcompwid(1): [...] the parameters are reset on each function exit (including nested function calls from within the completion widget) to the values they had when the function was entered. As a result, subcommand words are lost. Ouch. This is now fixed in the latest master branch of zsh[2] by simply defining 'words' as hidden (typeset -h), which removes the special meaning inside the emulated bash function. So let's do the same. Jonathan Nieder helped on the commit message. [1] http://bash-completion.alioth.debian.org/ [2] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=e880604f029088f32fb1ecc39213d720ae526aaa Reported-by: Stefan Haller <lists@haller-berlin.de> Comments-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>
2011-05-09git-grep: Learn PCRELibravatar Michał Kiedrowicz1-0/+1
This patch teaches git-grep the --perl-regexp/-P options (naming borrowed from GNU grep) in order to allow specifying PCRE regexes on the command line. PCRE has a number of features which make them more handy to use than POSIX regexes, like consistent escaping rules, extended character classes, ungreedy matching etc. git isn't build with PCRE support automatically. USE_LIBPCRE environment variable must be enabled (like `make USE_LIBPCRE=YesPlease`). Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-08completion: move private shopt shim for zsh to __git_ namespaceLibravatar Jonathan Nieder1-4/+8
Most zsh users probably probably do not expect a custom shopt function to enter their environment just because they ran "source ~/.git-completion.sh". Such namespace pollution makes development of other scripts confusing (because it makes the bash-specific shopt utility seem to be available in zsh) and makes git's tab completion script brittle (since any other shell snippet implementing some other subset of shopt will break it). Rename the shopt shim to the more innocuous __git_shopt to be a good citizen (with two underscores to avoid confusion with completion rules for a hypothetical "git shopt" command). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-06Merge branch 'sg/completion-cleanup'Libravatar Junio C Hamano1-161/+60
* sg/completion-cleanup: completion: remove unnecessary _get_comp_words_by_ref() invocations completion: don't modify the $cur variable in completion functions
2011-05-05contrib/completion: --line-number to git grepLibravatar Michał Kiedrowicz1-1/+1
The "-n" option of "git grep" gained a synonym "--line-number" with commit 7d6cb10b ("grep: Add the option '--line-number'", 2011-03-28). Teach bash-completion about it. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-02Merge branch 'jk/notes-ui-updates'Libravatar Junio C Hamano1-1/+1
* jk/notes-ui-updates: contrib/completion: --notes, --no-notes log/pretty-options: Document --[no-]notes and deprecate old notes options revision.c: make --no-notes reset --notes list revision.c: support --notes command-line option notes: refactor display notes default handling notes: refactor display notes extra refs field revision.c: refactor notes ref expansion notes: make expand_notes_ref globally accessible
2011-04-28completion: don't declare 'local words' to make zsh happyLibravatar SZEDER Gábor1-2/+6
The "_get_comp_words_by_ref -n := words" command from the bash_completion library reassembles a modified version of COMP_WORDS with ':' and '=' no longer treated as word separators and stores it in the ${words[@]} array. Git's programmable tab completion script uses this to abstract away the difference between bash v3's and bash v4's definitions of COMP_WORDS (bash v3 used shell words, while bash v4 breaks at separator characters); see v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work with bash v4, 2010-12-02). zsh has (or rather its completion functions have) another idea about what ${words[@]} should contain: the array is prepopulated with the words from the command it is completing. For reasons that are not well understood, when git-completion.bash reserves its own "words" variable with "local words", the variable becomes empty and cannot be changed from then on. So the completion script neglects the arguments it has seen, and words complete like git subcommand names. For example, typing "git log origi<TAB>" gives no completions because there are no "git origi..." commands. However, when this words variable is not declared as local but is just populated by _get_comp_words_by_ref() and then read in various completion functions, then zsh seems to be happy about it and our completion script works as expected. So, to get our completion script working again under zsh and to prevent the words variable from leaking into the shell environment under bash, we will only declare words as local when using bash. Reported-by: Stefan Haller <lists@haller-berlin.de> Suggested-by: Felipe Contreras <felipe.contreras@gmail.com> Explained-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-28completion: remove unnecessary _get_comp_words_by_ref() invocationsLibravatar SZEDER Gábor1-105/+11
In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref() to access completion-related variables. That was large change, and to make it easily reviewable, we invoked _get_comp_words_by_ref() in each completion function and systematically replaced every occurance of bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with variables set by _get_comp_words_by_ref(). This has the downside that _get_comp_words_by_ref() is invoked several times during a single completion. The worst offender is perhaps 'git log mas<TAB>': during the completion of 'master' _get_comp_words_by_ref() is invoked no less than six times. However, the variables $prev, $cword, and $words provided by _get_comp_words_by_ref() are not modified in any of the completion functions, and the previous commit ensures that the $cur variable is not modified as well. This makes it possible to invoke _get_comp_words_by_ref() to get those variables only once in our toplevel completion functions _git() and _gitk(), and all other completion functions will inherit them. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>