2011-04-27 03:23:35 +00:00
|
|
|
# bash/zsh completion support for core Git.
|
2006-09-28 09:31:25 +00:00
|
|
|
#
|
2007-05-24 05:36:46 +00:00
|
|
|
# Copyright (C) 2006,2007 Shawn O. Pearce <spearce@spearce.org>
|
2006-09-28 09:31:25 +00:00
|
|
|
# Conceptually based on gitcompletion (http://gitweb.hawaga.org.uk/).
|
2007-05-24 05:36:46 +00:00
|
|
|
# Distributed under the GNU General Public License, version 2.0.
|
2006-09-28 09:31:25 +00:00
|
|
|
#
|
|
|
|
# The contained completion routines provide support for completing:
|
|
|
|
#
|
|
|
|
# *) local and remote branch names
|
|
|
|
# *) local and remote tag names
|
|
|
|
# *) .git/remotes file names
|
|
|
|
# *) git 'subcommands'
|
2015-11-19 22:52:12 +00:00
|
|
|
# *) git email aliases for git-send-email
|
2006-09-28 09:31:25 +00:00
|
|
|
# *) tree paths within 'ref:path/to/file' expressions
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
# *) file paths within current working directory and index
|
2007-05-24 05:36:46 +00:00
|
|
|
# *) common --long-options
|
2006-09-28 09:31:25 +00:00
|
|
|
#
|
|
|
|
# To use these routines:
|
|
|
|
#
|
2014-12-15 14:34:28 +00:00
|
|
|
# 1) Copy this file to somewhere (e.g. ~/.git-completion.bash).
|
2011-04-27 03:23:35 +00:00
|
|
|
# 2) Add the following line to your .bashrc/.zshrc:
|
2014-12-15 14:34:28 +00:00
|
|
|
# source ~/.git-completion.bash
|
2012-05-22 20:46:40 +00:00
|
|
|
# 3) Consider changing your PS1 to also show the current branch,
|
|
|
|
# see git-prompt.sh for details.
|
2014-06-12 18:49:29 +00:00
|
|
|
#
|
|
|
|
# If you use complex aliases of form '!f() { ... }; f', you can use the null
|
|
|
|
# command ':' as the first command in the function body to declare the desired
|
|
|
|
# completion style. For example '!f() { : git commit ; ... }; f' will
|
|
|
|
# tell the completion to use commit completion. This also works with aliases
|
|
|
|
# of form "!sh -c '...'". For example, "!sh -c ': git commit ; ... '".
|
2006-09-28 09:31:25 +00:00
|
|
|
|
2008-07-15 05:52:04 +00:00
|
|
|
case "$COMP_WORDBREAKS" in
|
|
|
|
*:*) : great ;;
|
|
|
|
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
|
|
|
|
esac
|
|
|
|
|
2009-01-15 16:02:23 +00:00
|
|
|
# __gitdir accepts 0 or 1 arguments (i.e., location)
|
|
|
|
# returns location of .git repo
|
2006-11-05 11:21:57 +00:00
|
|
|
__gitdir ()
|
|
|
|
{
|
2009-01-15 16:02:21 +00:00
|
|
|
if [ -z "${1-}" ]; then
|
2009-02-11 18:03:26 +00:00
|
|
|
if [ -n "${__git_dir-}" ]; then
|
2006-11-28 17:12:26 +00:00
|
|
|
echo "$__git_dir"
|
completion: respect $GIT_DIR
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-05-09 00:44:35 +00:00
|
|
|
elif [ -n "${GIT_DIR-}" ]; then
|
|
|
|
test -d "${GIT_DIR-}" || return 1
|
|
|
|
echo "$GIT_DIR"
|
2006-11-28 17:12:26 +00:00
|
|
|
elif [ -d .git ]; then
|
|
|
|
echo .git
|
|
|
|
else
|
|
|
|
git rev-parse --git-dir 2>/dev/null
|
|
|
|
fi
|
|
|
|
elif [ -d "$1/.git" ]; then
|
|
|
|
echo "$1/.git"
|
|
|
|
else
|
|
|
|
echo "$1"
|
|
|
|
fi
|
2006-11-05 11:21:57 +00:00
|
|
|
}
|
|
|
|
|
2010-12-15 04:57:58 +00:00
|
|
|
# The following function is based on code from:
|
|
|
|
#
|
|
|
|
# bash_completion - programmable completion functions for bash 3.2+
|
|
|
|
#
|
|
|
|
# Copyright © 2006-2008, Ian Macdonald <ian@caliban.org>
|
|
|
|
# © 2009-2010, Bash Completion Maintainers
|
|
|
|
# <bash-completion-devel@lists.alioth.debian.org>
|
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 2, or (at your option)
|
|
|
|
# any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program; if not, write to the Free Software Foundation,
|
|
|
|
# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
#
|
|
|
|
# The latest version of this software can be obtained here:
|
|
|
|
#
|
|
|
|
# http://bash-completion.alioth.debian.org/
|
|
|
|
#
|
|
|
|
# RELEASE: 2.x
|
|
|
|
|
|
|
|
# This function can be used to access a tokenized list of words
|
|
|
|
# on the command line:
|
|
|
|
#
|
|
|
|
# __git_reassemble_comp_words_by_ref '=:'
|
|
|
|
# if test "${words_[cword_-1]}" = -w
|
|
|
|
# then
|
|
|
|
# ...
|
|
|
|
# fi
|
|
|
|
#
|
|
|
|
# The argument should be a collection of characters from the list of
|
|
|
|
# word completion separators (COMP_WORDBREAKS) to treat as ordinary
|
|
|
|
# characters.
|
|
|
|
#
|
|
|
|
# This is roughly equivalent to going back in time and setting
|
|
|
|
# COMP_WORDBREAKS to exclude those characters. The intent is to
|
|
|
|
# make option types like --date=<type> and <rev>:<path> easy to
|
|
|
|
# recognize by treating each shell word as a single token.
|
|
|
|
#
|
|
|
|
# It is best not to set COMP_WORDBREAKS directly because the value is
|
|
|
|
# shared with other completion scripts. By the time the completion
|
|
|
|
# function gets called, COMP_WORDS has already been populated so local
|
|
|
|
# changes to COMP_WORDBREAKS have no effect.
|
|
|
|
#
|
|
|
|
# Output: words_, cword_, cur_.
|
|
|
|
|
|
|
|
__git_reassemble_comp_words_by_ref()
|
|
|
|
{
|
|
|
|
local exclude i j first
|
|
|
|
# Which word separators to exclude?
|
|
|
|
exclude="${1//[^$COMP_WORDBREAKS]}"
|
|
|
|
cword_=$COMP_CWORD
|
|
|
|
if [ -z "$exclude" ]; then
|
|
|
|
words_=("${COMP_WORDS[@]}")
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
# List of word completion separators has shrunk;
|
|
|
|
# re-assemble words to complete.
|
|
|
|
for ((i=0, j=0; i < ${#COMP_WORDS[@]}; i++, j++)); do
|
|
|
|
# Append each nonempty word consisting of just
|
|
|
|
# word separator characters to the current word.
|
|
|
|
first=t
|
|
|
|
while
|
|
|
|
[ $i -gt 0 ] &&
|
|
|
|
[ -n "${COMP_WORDS[$i]}" ] &&
|
|
|
|
# word consists of excluded word separators
|
|
|
|
[ "${COMP_WORDS[$i]//[^$exclude]}" = "${COMP_WORDS[$i]}" ]
|
|
|
|
do
|
|
|
|
# Attach to the previous token,
|
|
|
|
# unless the previous token is the command name.
|
|
|
|
if [ $j -ge 2 ] && [ -n "$first" ]; then
|
|
|
|
((j--))
|
|
|
|
fi
|
|
|
|
first=
|
|
|
|
words_[$j]=${words_[j]}${COMP_WORDS[i]}
|
|
|
|
if [ $i = $COMP_CWORD ]; then
|
|
|
|
cword_=$j
|
|
|
|
fi
|
|
|
|
if (($i < ${#COMP_WORDS[@]} - 1)); then
|
|
|
|
((i++))
|
|
|
|
else
|
|
|
|
# Done.
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
words_[$j]=${words_[j]}${COMP_WORDS[i]}
|
|
|
|
if [ $i = $COMP_CWORD ]; then
|
|
|
|
cword_=$j
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
if ! type _get_comp_words_by_ref >/dev/null 2>&1; then
|
|
|
|
_get_comp_words_by_ref ()
|
|
|
|
{
|
2010-12-15 04:57:58 +00:00
|
|
|
local exclude cur_ words_ cword_
|
|
|
|
if [ "$1" = "-n" ]; then
|
|
|
|
exclude=$2
|
|
|
|
shift 2
|
|
|
|
fi
|
|
|
|
__git_reassemble_comp_words_by_ref "$exclude"
|
|
|
|
cur_=${words_[cword_]}
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
while [ $# -gt 0 ]; do
|
|
|
|
case "$1" in
|
|
|
|
cur)
|
2010-12-15 04:57:58 +00:00
|
|
|
cur=$cur_
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
;;
|
|
|
|
prev)
|
2010-12-15 04:57:58 +00:00
|
|
|
prev=${words_[$cword_-1]}
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
;;
|
|
|
|
words)
|
2010-12-15 04:57:58 +00:00
|
|
|
words=("${words_[@]}")
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
;;
|
|
|
|
cword)
|
2010-12-15 04:57:58 +00:00
|
|
|
cword=$cword_
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
}
|
|
|
|
fi
|
|
|
|
|
2014-01-05 10:18:03 +00:00
|
|
|
__gitcompappend ()
|
2013-04-10 06:57:53 +00:00
|
|
|
{
|
2015-04-08 05:45:58 +00:00
|
|
|
local x i=${#COMPREPLY[@]}
|
2013-04-10 06:57:55 +00:00
|
|
|
for x in $1; do
|
|
|
|
if [[ "$x" == "$3"* ]]; then
|
|
|
|
COMPREPLY[i++]="$2$x$4"
|
|
|
|
fi
|
|
|
|
done
|
2013-04-10 06:57:53 +00:00
|
|
|
}
|
|
|
|
|
2014-01-05 10:18:03 +00:00
|
|
|
__gitcompadd ()
|
|
|
|
{
|
|
|
|
COMPREPLY=()
|
|
|
|
__gitcompappend "$@"
|
|
|
|
}
|
|
|
|
|
2013-04-10 06:57:55 +00:00
|
|
|
# Generates completion reply, appending a space to possible completion words,
|
|
|
|
# if necessary.
|
2011-10-08 14:54:35 +00:00
|
|
|
# It accepts 1 to 4 arguments:
|
|
|
|
# 1: List of possible completion words.
|
|
|
|
# 2: A prefix to be added to each possible completion word (optional).
|
|
|
|
# 3: Generate possible completion matches for this word (optional).
|
|
|
|
# 4: A suffix to be appended to each possible completion word (optional).
|
2007-02-04 07:38:27 +00:00
|
|
|
__gitcomp ()
|
|
|
|
{
|
2012-02-02 19:48:08 +00:00
|
|
|
local cur_="${3-$cur}"
|
2011-04-28 16:01:51 +00:00
|
|
|
|
|
|
|
case "$cur_" in
|
2008-03-05 19:07:49 +00:00
|
|
|
--*=)
|
|
|
|
;;
|
|
|
|
*)
|
2013-04-10 06:57:56 +00:00
|
|
|
local c i=0 IFS=$' \t\n'
|
|
|
|
for c in $1; do
|
|
|
|
c="$c${4-}"
|
|
|
|
if [[ $c == "$cur_"* ]]; then
|
2013-04-10 06:57:57 +00:00
|
|
|
case $c in
|
|
|
|
--*=*|*.) ;;
|
|
|
|
*) c="$c " ;;
|
|
|
|
esac
|
2013-04-10 06:57:56 +00:00
|
|
|
COMPREPLY[i++]="${2-}$c"
|
|
|
|
fi
|
|
|
|
done
|
2008-03-05 19:07:49 +00:00
|
|
|
;;
|
|
|
|
esac
|
2007-02-04 07:38:27 +00:00
|
|
|
}
|
|
|
|
|
2014-01-05 10:18:03 +00:00
|
|
|
# Variation of __gitcomp_nl () that appends to the existing list of
|
|
|
|
# completion candidates, COMPREPLY.
|
|
|
|
__gitcomp_nl_append ()
|
|
|
|
{
|
|
|
|
local IFS=$'\n'
|
|
|
|
__gitcompappend "$1" "${2-}" "${3-$cur}" "${4- }"
|
|
|
|
}
|
|
|
|
|
2013-04-10 06:57:55 +00:00
|
|
|
# Generates completion reply from newline-separated possible completion words
|
|
|
|
# by appending a space to all of them.
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
# It accepts 1 to 4 arguments:
|
|
|
|
# 1: List of possible completion words, separated by a single newline.
|
|
|
|
# 2: A prefix to be added to each possible completion word (optional).
|
|
|
|
# 3: Generate possible completion matches for this word (optional).
|
|
|
|
# 4: A suffix to be appended to each possible completion word instead of
|
|
|
|
# the default space (optional). If specified but empty, nothing is
|
|
|
|
# appended.
|
|
|
|
__gitcomp_nl ()
|
|
|
|
{
|
2014-01-05 10:18:03 +00:00
|
|
|
COMPREPLY=()
|
|
|
|
__gitcomp_nl_append "$@"
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
}
|
|
|
|
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
# Generates completion reply with compgen from newline-separated possible
|
|
|
|
# completion filenames.
|
|
|
|
# It accepts 1 to 3 arguments:
|
|
|
|
# 1: List of possible completion filenames, separated by a single newline.
|
|
|
|
# 2: A directory prefix to be added to each possible completion filename
|
|
|
|
# (optional).
|
|
|
|
# 3: Generate possible completion matches for this word (optional).
|
|
|
|
__gitcomp_file ()
|
|
|
|
{
|
|
|
|
local IFS=$'\n'
|
|
|
|
|
|
|
|
# XXX does not work when the directory prefix contains a tilde,
|
|
|
|
# since tilde expansion is not applied.
|
|
|
|
# This means that COMPREPLY will be empty and Bash default
|
|
|
|
# completion will be used.
|
2013-04-27 20:10:02 +00:00
|
|
|
__gitcompadd "$1" "${2-}" "${3-$cur}" ""
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
2013-04-27 20:10:05 +00:00
|
|
|
# use a hack to enable file mode in bash < 4
|
2013-04-27 20:10:06 +00:00
|
|
|
compopt -o filenames +o nospace 2>/dev/null ||
|
2013-04-27 20:10:05 +00:00
|
|
|
compgen -f /non-existing-dir/ > /dev/null
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
}
|
|
|
|
|
2013-04-27 20:10:03 +00:00
|
|
|
# Execute 'git ls-files', unless the --committable option is specified, in
|
|
|
|
# which case it runs 'git diff-index' to find out the files that can be
|
|
|
|
# committed. It return paths relative to the directory specified in the first
|
|
|
|
# argument, and using the options specified in the second argument.
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
__git_ls_files_helper ()
|
|
|
|
{
|
2014-10-09 20:45:21 +00:00
|
|
|
if [ "$2" == "--committable" ]; then
|
|
|
|
git -C "$1" diff-index --name-only --relative HEAD
|
|
|
|
else
|
|
|
|
# NOTE: $2 is not quoted in order to support multiple options
|
|
|
|
git -C "$1" ls-files --exclude-standard $2
|
|
|
|
fi 2>/dev/null
|
2013-03-11 12:21:27 +00:00
|
|
|
}
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
# __git_index_files accepts 1 or 2 arguments:
|
|
|
|
# 1: Options to pass to ls-files (required).
|
|
|
|
# 2: A directory path (optional).
|
|
|
|
# If provided, only files within the specified directory are listed.
|
|
|
|
# Sub directories are never recursed. Path must have a trailing
|
|
|
|
# slash.
|
|
|
|
__git_index_files ()
|
|
|
|
{
|
2013-04-27 20:10:07 +00:00
|
|
|
local dir="$(__gitdir)" root="${2-.}" file
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
if [ -d "$dir" ]; then
|
2013-04-27 20:10:07 +00:00
|
|
|
__git_ls_files_helper "$root" "$1" |
|
|
|
|
while read -r file; do
|
|
|
|
case "$file" in
|
|
|
|
?*/*) echo "${file%%/*}" ;;
|
|
|
|
*) echo "$file" ;;
|
|
|
|
esac
|
|
|
|
done | sort | uniq
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2006-11-27 09:44:47 +00:00
|
|
|
__git_heads ()
|
|
|
|
{
|
completion: remove broken dead code from __git_heads() and __git_tags()
__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-08 14:54:43 +00:00
|
|
|
local dir="$(__gitdir)"
|
2006-11-27 09:44:47 +00:00
|
|
|
if [ -d "$dir" ]; then
|
2008-09-19 22:15:25 +00:00
|
|
|
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
|
|
|
|
refs/heads
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2007-09-01 03:47:01 +00:00
|
|
|
__git_tags ()
|
|
|
|
{
|
completion: remove broken dead code from __git_heads() and __git_tags()
__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-08 14:54:43 +00:00
|
|
|
local dir="$(__gitdir)"
|
2007-09-01 03:47:01 +00:00
|
|
|
if [ -d "$dir" ]; then
|
2008-09-19 22:15:25 +00:00
|
|
|
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
|
|
|
|
refs/tags
|
2007-09-01 03:47:01 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2010-10-12 21:38:12 +00:00
|
|
|
# __git_refs accepts 0, 1 (to pass to __gitdir), or 2 arguments
|
|
|
|
# presence of 2nd argument means use the guess heuristic employed
|
|
|
|
# by checkout for tracking branches
|
2006-09-28 09:31:25 +00:00
|
|
|
__git_refs ()
|
|
|
|
{
|
2011-10-08 14:54:38 +00:00
|
|
|
local i hash dir="$(__gitdir "${1-}")" track="${2-}"
|
2011-04-28 16:01:52 +00:00
|
|
|
local format refs
|
2006-11-05 11:21:57 +00:00
|
|
|
if [ -d "$dir" ]; then
|
2008-11-28 00:46:38 +00:00
|
|
|
case "$cur" in
|
|
|
|
refs|refs/*)
|
|
|
|
format="refname"
|
|
|
|
refs="${cur%/*}"
|
2010-10-12 21:38:12 +00:00
|
|
|
track=""
|
2008-11-28 00:46:38 +00:00
|
|
|
;;
|
|
|
|
*)
|
2010-03-17 09:20:35 +00:00
|
|
|
for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD; do
|
|
|
|
if [ -e "$dir/$i" ]; then echo $i; fi
|
|
|
|
done
|
2008-11-28 00:46:38 +00:00
|
|
|
format="refname:short"
|
|
|
|
refs="refs/tags refs/heads refs/remotes"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
git --git-dir="$dir" for-each-ref --format="%($format)" \
|
|
|
|
$refs
|
2010-10-12 21:38:12 +00:00
|
|
|
if [ -n "$track" ]; then
|
|
|
|
# employ the heuristic used by git checkout
|
|
|
|
# Try to find a remote branch that matches the completion word
|
|
|
|
# but only output if the branch name is unique
|
|
|
|
local ref entry
|
|
|
|
git --git-dir="$dir" for-each-ref --shell --format="ref=%(refname:short)" \
|
|
|
|
"refs/remotes/" | \
|
2011-12-21 15:54:14 +00:00
|
|
|
while read -r entry; do
|
2010-10-12 21:38:12 +00:00
|
|
|
eval "$entry"
|
|
|
|
ref="${ref#*/}"
|
|
|
|
if [[ "$ref" == "$cur"* ]]; then
|
|
|
|
echo "$ref"
|
|
|
|
fi
|
Completion must sort before using uniq
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-23 14:02:22 +00:00
|
|
|
done | sort | uniq -u
|
2010-10-12 21:38:12 +00:00
|
|
|
fi
|
2006-11-27 08:42:32 +00:00
|
|
|
return
|
2006-09-28 09:31:25 +00:00
|
|
|
fi
|
2011-10-08 14:54:39 +00:00
|
|
|
case "$cur" in
|
|
|
|
refs|refs/*)
|
|
|
|
git ls-remote "$dir" "$cur*" 2>/dev/null | \
|
2011-12-21 15:54:14 +00:00
|
|
|
while read -r hash i; do
|
2011-10-08 14:54:39 +00:00
|
|
|
case "$i" in
|
|
|
|
*^{}) ;;
|
|
|
|
*) echo "$i" ;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
;;
|
|
|
|
*)
|
2013-05-29 03:20:48 +00:00
|
|
|
echo "HEAD"
|
2014-10-14 10:49:45 +00:00
|
|
|
git for-each-ref --format="%(refname:short)" -- \
|
|
|
|
"refs/remotes/$dir/" 2>/dev/null | sed -e "s#^$dir/##"
|
2011-10-08 14:54:39 +00:00
|
|
|
;;
|
|
|
|
esac
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2009-01-15 16:02:23 +00:00
|
|
|
# __git_refs2 requires 1 argument (to pass to __git_refs)
|
2006-09-28 09:31:25 +00:00
|
|
|
__git_refs2 ()
|
|
|
|
{
|
2006-11-28 17:12:26 +00:00
|
|
|
local i
|
|
|
|
for i in $(__git_refs "$1"); do
|
|
|
|
echo "$i:$i"
|
2006-09-28 09:31:25 +00:00
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2009-01-15 16:02:23 +00:00
|
|
|
# __git_refs_remotes requires 1 argument (to pass to ls-remote)
|
2006-11-27 09:44:47 +00:00
|
|
|
__git_refs_remotes ()
|
|
|
|
{
|
2011-10-08 14:54:41 +00:00
|
|
|
local i hash
|
|
|
|
git ls-remote "$1" 'refs/heads/*' 2>/dev/null | \
|
2011-12-21 15:54:14 +00:00
|
|
|
while read -r hash i; do
|
2011-10-08 14:54:41 +00:00
|
|
|
echo "$i:refs/remotes/$1/${i#refs/heads/}"
|
2006-11-27 09:44:47 +00:00
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
__git_remotes ()
|
|
|
|
{
|
2015-03-04 14:10:29 +00:00
|
|
|
local d="$(__gitdir)"
|
2012-02-02 09:05:29 +00:00
|
|
|
test -d "$d/remotes" && ls -1 "$d/remotes"
|
2015-03-04 14:10:29 +00:00
|
|
|
git --git-dir="$d" remote
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_list_merge_strategies ()
|
2006-11-27 08:40:47 +00:00
|
|
|
{
|
2008-08-20 21:13:42 +00:00
|
|
|
git merge -s help 2>&1 |
|
|
|
|
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
|
|
|
|
s/\.$//
|
|
|
|
s/.*://
|
|
|
|
s/^[ ]*//
|
|
|
|
s/[ ]*$//
|
2006-11-27 08:40:47 +00:00
|
|
|
p
|
2008-08-20 21:13:42 +00:00
|
|
|
}'
|
2006-11-27 08:40:47 +00:00
|
|
|
}
|
2009-11-18 00:49:10 +00:00
|
|
|
|
|
|
|
__git_merge_strategies=
|
|
|
|
# 'git merge -s help' (and thus detection of the merge strategy
|
|
|
|
# list) fails, unfortunately, if run outside of any git working
|
|
|
|
# tree. __git_merge_strategies is set to the empty string in
|
|
|
|
# that case, and the detection will be repeated the next time it
|
|
|
|
# is needed.
|
|
|
|
__git_compute_merge_strategies ()
|
|
|
|
{
|
2012-02-02 19:26:15 +00:00
|
|
|
test -n "$__git_merge_strategies" ||
|
|
|
|
__git_merge_strategies=$(__git_list_merge_strategies)
|
2009-11-18 00:49:10 +00:00
|
|
|
}
|
2006-11-27 08:40:47 +00:00
|
|
|
|
bash: complete 'git diff ...branc<TAB>'
While doing a final sanity check before merging a topic Bsomething, it
is a good idea to review what damage Bsomething branch would make, by
running:
$ git diff ...Bsomething
Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'. This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'<tree>:<path>' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'. Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support '<tree>:<path>'.
To support both '...<ref>' and '<tree>:<path>' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file(). The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.
This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 18:12:29 +00:00
|
|
|
__git_complete_revlist_file ()
|
2006-09-28 09:31:25 +00:00
|
|
|
{
|
2011-04-28 16:01:52 +00:00
|
|
|
local pfx ls ref cur_="$cur"
|
2011-04-28 16:01:51 +00:00
|
|
|
case "$cur_" in
|
bash: complete 'git diff ...branc<TAB>'
While doing a final sanity check before merging a topic Bsomething, it
is a good idea to review what damage Bsomething branch would make, by
running:
$ git diff ...Bsomething
Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'. This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'<tree>:<path>' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'. Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support '<tree>:<path>'.
To support both '...<ref>' and '<tree>:<path>' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file(). The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.
This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 18:12:29 +00:00
|
|
|
*..?*:*)
|
|
|
|
return
|
|
|
|
;;
|
2006-09-28 09:31:25 +00:00
|
|
|
?*:*)
|
2011-04-28 16:01:51 +00:00
|
|
|
ref="${cur_%%:*}"
|
|
|
|
cur_="${cur_#*:}"
|
|
|
|
case "$cur_" in
|
2006-09-28 09:31:25 +00:00
|
|
|
?*/*)
|
2011-04-28 16:01:51 +00:00
|
|
|
pfx="${cur_%/*}"
|
|
|
|
cur_="${cur_##*/}"
|
2006-09-28 09:31:25 +00:00
|
|
|
ls="$ref:$pfx"
|
|
|
|
pfx="$pfx/"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
ls="$ref"
|
|
|
|
;;
|
2011-03-10 18:12:28 +00:00
|
|
|
esac
|
2008-07-15 05:52:04 +00:00
|
|
|
|
|
|
|
case "$COMP_WORDBREAKS" in
|
|
|
|
*:*) : great ;;
|
|
|
|
*) pfx="$ref:$pfx" ;;
|
|
|
|
esac
|
|
|
|
|
2013-01-11 08:06:22 +00:00
|
|
|
__gitcomp_nl "$(git --git-dir="$(__gitdir)" ls-tree "$ls" 2>/dev/null \
|
2008-07-14 00:22:03 +00:00
|
|
|
| sed '/^100... blob /{
|
|
|
|
s,^.* ,,
|
|
|
|
s,$, ,
|
|
|
|
}
|
|
|
|
/^120000 blob /{
|
|
|
|
s,^.* ,,
|
|
|
|
s,$, ,
|
|
|
|
}
|
2006-09-28 09:31:25 +00:00
|
|
|
/^040000 tree /{
|
|
|
|
s,^.* ,,
|
|
|
|
s,$,/,
|
|
|
|
}
|
|
|
|
s/^.* //')" \
|
2012-05-01 18:42:56 +00:00
|
|
|
"$pfx" "$cur_" ""
|
2006-09-28 09:31:25 +00:00
|
|
|
;;
|
2006-11-27 08:41:43 +00:00
|
|
|
*...*)
|
2011-04-28 16:01:51 +00:00
|
|
|
pfx="${cur_%...*}..."
|
|
|
|
cur_="${cur_#*...}"
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
|
2006-11-27 08:41:43 +00:00
|
|
|
;;
|
|
|
|
*..*)
|
2011-04-28 16:01:51 +00:00
|
|
|
pfx="${cur_%..*}.."
|
|
|
|
cur_="${cur_#*..}"
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
|
2007-02-04 07:38:43 +00:00
|
|
|
;;
|
2006-11-27 08:41:43 +00:00
|
|
|
*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2006-11-27 08:41:43 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
bash: complete 'git diff ...branc<TAB>'
While doing a final sanity check before merging a topic Bsomething, it
is a good idea to review what damage Bsomething branch would make, by
running:
$ git diff ...Bsomething
Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'. This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'<tree>:<path>' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'. Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support '<tree>:<path>'.
To support both '...<ref>' and '<tree>:<path>' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file(). The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.
This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 18:12:29 +00:00
|
|
|
|
2013-04-27 20:10:03 +00:00
|
|
|
# __git_complete_index_file requires 1 argument:
|
|
|
|
# 1: the options to pass to ls-file
|
|
|
|
#
|
|
|
|
# The exception is --committable, which finds the files appropriate commit.
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
__git_complete_index_file ()
|
|
|
|
{
|
2013-04-27 20:10:04 +00:00
|
|
|
local pfx="" cur_="$cur"
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
case "$cur_" in
|
|
|
|
?*/*)
|
|
|
|
pfx="${cur_%/*}"
|
|
|
|
cur_="${cur_##*/}"
|
|
|
|
pfx="${pfx}/"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2014-10-09 20:45:21 +00:00
|
|
|
__gitcomp_file "$(__git_index_files "$1" ${pfx:+"$pfx"})" "$pfx" "$cur_"
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
}
|
|
|
|
|
bash: complete 'git diff ...branc<TAB>'
While doing a final sanity check before merging a topic Bsomething, it
is a good idea to review what damage Bsomething branch would make, by
running:
$ git diff ...Bsomething
Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'. This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'<tree>:<path>' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'. Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support '<tree>:<path>'.
To support both '...<ref>' and '<tree>:<path>' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file(). The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.
This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 18:12:29 +00:00
|
|
|
__git_complete_file ()
|
|
|
|
{
|
|
|
|
__git_complete_revlist_file
|
|
|
|
}
|
|
|
|
|
|
|
|
__git_complete_revlist ()
|
|
|
|
{
|
|
|
|
__git_complete_revlist_file
|
|
|
|
}
|
|
|
|
|
2009-03-06 04:39:31 +00:00
|
|
|
__git_complete_remote_or_refspec ()
|
|
|
|
{
|
2011-04-28 16:01:51 +00:00
|
|
|
local cur_="$cur" cmd="${words[1]}"
|
2009-03-06 04:39:33 +00:00
|
|
|
local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
|
2012-02-22 08:58:10 +00:00
|
|
|
if [ "$cmd" = "remote" ]; then
|
2012-02-22 08:58:11 +00:00
|
|
|
((c++))
|
2012-02-22 08:58:10 +00:00
|
|
|
fi
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
while [ $c -lt $cword ]; do
|
|
|
|
i="${words[c]}"
|
2009-03-06 04:39:31 +00:00
|
|
|
case "$i" in
|
2009-12-12 10:21:46 +00:00
|
|
|
--mirror) [ "$cmd" = "push" ] && no_complete_refspec=1 ;;
|
|
|
|
--all)
|
|
|
|
case "$cmd" in
|
|
|
|
push) no_complete_refspec=1 ;;
|
|
|
|
fetch)
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
*) ;;
|
|
|
|
esac
|
|
|
|
;;
|
2009-03-06 04:39:31 +00:00
|
|
|
-*) ;;
|
|
|
|
*) remote="$i"; break ;;
|
|
|
|
esac
|
2012-02-22 08:58:11 +00:00
|
|
|
((c++))
|
2009-03-06 04:39:31 +00:00
|
|
|
done
|
|
|
|
if [ -z "$remote" ]; then
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)"
|
2009-03-06 04:39:31 +00:00
|
|
|
return
|
|
|
|
fi
|
2009-03-06 04:39:33 +00:00
|
|
|
if [ $no_complete_refspec = 1 ]; then
|
|
|
|
return
|
|
|
|
fi
|
2009-03-06 04:39:31 +00:00
|
|
|
[ "$remote" = "." ] && remote=
|
2011-04-28 16:01:51 +00:00
|
|
|
case "$cur_" in
|
2009-03-06 04:39:31 +00:00
|
|
|
*:*)
|
|
|
|
case "$COMP_WORDBREAKS" in
|
|
|
|
*:*) : great ;;
|
2011-04-28 16:01:51 +00:00
|
|
|
*) pfx="${cur_%%:*}:" ;;
|
2009-03-06 04:39:31 +00:00
|
|
|
esac
|
2011-04-28 16:01:51 +00:00
|
|
|
cur_="${cur_#*:}"
|
2009-03-06 04:39:31 +00:00
|
|
|
lhs=0
|
|
|
|
;;
|
|
|
|
+*)
|
|
|
|
pfx="+"
|
2011-04-28 16:01:51 +00:00
|
|
|
cur_="${cur_#+}"
|
2009-03-06 04:39:31 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
case "$cmd" in
|
|
|
|
fetch)
|
|
|
|
if [ $lhs = 1 ]; then
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs2 "$remote")" "$pfx" "$cur_"
|
2009-03-06 04:39:31 +00:00
|
|
|
else
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
|
2009-03-06 04:39:31 +00:00
|
|
|
fi
|
|
|
|
;;
|
2012-02-22 08:58:10 +00:00
|
|
|
pull|remote)
|
2009-03-06 04:39:31 +00:00
|
|
|
if [ $lhs = 1 ]; then
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs "$remote")" "$pfx" "$cur_"
|
2009-03-06 04:39:31 +00:00
|
|
|
else
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
|
2009-03-06 04:39:31 +00:00
|
|
|
fi
|
|
|
|
;;
|
|
|
|
push)
|
|
|
|
if [ $lhs = 1 ]; then
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
|
2009-03-06 04:39:31 +00:00
|
|
|
else
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs "$remote")" "$pfx" "$cur_"
|
2009-03-06 04:39:31 +00:00
|
|
|
fi
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2009-03-06 16:30:44 +00:00
|
|
|
__git_complete_strategy ()
|
|
|
|
{
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_compute_merge_strategies
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
case "$prev" in
|
2009-03-06 16:30:44 +00:00
|
|
|
-s|--strategy)
|
2009-11-18 00:49:10 +00:00
|
|
|
__gitcomp "$__git_merge_strategies"
|
2009-03-06 16:30:44 +00:00
|
|
|
return 0
|
|
|
|
esac
|
|
|
|
case "$cur" in
|
|
|
|
--strategy=*)
|
2009-11-18 00:49:10 +00:00
|
|
|
__gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
|
2009-03-06 16:30:44 +00:00
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2013-01-24 23:08:37 +00:00
|
|
|
__git_commands () {
|
|
|
|
if test -n "${GIT_TESTING_COMMAND_COMPLETION:-}"
|
|
|
|
then
|
|
|
|
printf "%s" "${GIT_TESTING_COMMAND_COMPLETION}"
|
|
|
|
else
|
|
|
|
git help -a|egrep '^ [a-zA-Z0-9]'
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_list_all_commands ()
|
2006-11-27 08:41:01 +00:00
|
|
|
{
|
|
|
|
local i IFS=" "$'\n'
|
2013-01-24 23:08:37 +00:00
|
|
|
for i in $(__git_commands)
|
2008-07-24 00:07:23 +00:00
|
|
|
do
|
|
|
|
case $i in
|
|
|
|
*--*) : helper pattern;;
|
|
|
|
*) echo $i;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_all_commands=
|
|
|
|
__git_compute_all_commands ()
|
|
|
|
{
|
2012-02-02 19:26:15 +00:00
|
|
|
test -n "$__git_all_commands" ||
|
|
|
|
__git_all_commands=$(__git_list_all_commands)
|
2009-11-18 00:49:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
__git_list_porcelain_commands ()
|
2008-07-24 00:07:23 +00:00
|
|
|
{
|
|
|
|
local i IFS=" "$'\n'
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_compute_all_commands
|
2012-11-14 00:49:30 +00:00
|
|
|
for i in $__git_all_commands
|
2006-11-27 08:41:01 +00:00
|
|
|
do
|
|
|
|
case $i in
|
2007-12-15 11:11:54 +00:00
|
|
|
*--*) : helper pattern;;
|
2007-02-04 07:38:30 +00:00
|
|
|
applymbox) : ask gittus;;
|
|
|
|
applypatch) : ask gittus;;
|
|
|
|
archimport) : import;;
|
2007-02-04 07:38:21 +00:00
|
|
|
cat-file) : plumbing;;
|
2007-05-19 21:35:21 +00:00
|
|
|
check-attr) : plumbing;;
|
2013-01-06 16:58:13 +00:00
|
|
|
check-ignore) : plumbing;;
|
2013-07-13 00:53:10 +00:00
|
|
|
check-mailmap) : plumbing;;
|
2006-11-27 08:41:01 +00:00
|
|
|
check-ref-format) : plumbing;;
|
2008-08-26 17:11:44 +00:00
|
|
|
checkout-index) : plumbing;;
|
2015-12-11 12:05:00 +00:00
|
|
|
column) : internal helper;;
|
2006-11-27 08:41:01 +00:00
|
|
|
commit-tree) : plumbing;;
|
2008-08-26 17:11:44 +00:00
|
|
|
count-objects) : infrequent;;
|
2015-05-05 16:33:13 +00:00
|
|
|
credential) : credentials;;
|
|
|
|
credential-*) : credentials helper;;
|
2007-02-04 07:38:30 +00:00
|
|
|
cvsexportcommit) : export;;
|
|
|
|
cvsimport) : import;;
|
2006-11-27 08:41:01 +00:00
|
|
|
cvsserver) : daemon;;
|
|
|
|
daemon) : daemon;;
|
2007-05-24 05:01:02 +00:00
|
|
|
diff-files) : plumbing;;
|
|
|
|
diff-index) : plumbing;;
|
|
|
|
diff-tree) : plumbing;;
|
2007-02-12 00:55:22 +00:00
|
|
|
fast-import) : import;;
|
2008-08-26 17:11:44 +00:00
|
|
|
fast-export) : export;;
|
2007-02-04 07:38:30 +00:00
|
|
|
fsck-objects) : plumbing;;
|
2006-11-27 08:41:01 +00:00
|
|
|
fetch-pack) : plumbing;;
|
2007-02-04 07:38:30 +00:00
|
|
|
fmt-merge-msg) : plumbing;;
|
2007-05-19 21:35:21 +00:00
|
|
|
for-each-ref) : plumbing;;
|
2006-11-27 08:41:01 +00:00
|
|
|
hash-object) : plumbing;;
|
|
|
|
http-*) : transport;;
|
|
|
|
index-pack) : plumbing;;
|
2007-02-04 07:38:30 +00:00
|
|
|
init-db) : deprecated;;
|
2006-11-27 08:41:01 +00:00
|
|
|
local-fetch) : plumbing;;
|
2008-08-26 17:11:44 +00:00
|
|
|
ls-files) : plumbing;;
|
|
|
|
ls-remote) : plumbing;;
|
|
|
|
ls-tree) : plumbing;;
|
2006-11-27 08:41:01 +00:00
|
|
|
mailinfo) : plumbing;;
|
|
|
|
mailsplit) : plumbing;;
|
|
|
|
merge-*) : plumbing;;
|
|
|
|
mktree) : plumbing;;
|
|
|
|
mktag) : plumbing;;
|
|
|
|
pack-objects) : plumbing;;
|
|
|
|
pack-redundant) : plumbing;;
|
|
|
|
pack-refs) : plumbing;;
|
|
|
|
parse-remote) : plumbing;;
|
|
|
|
patch-id) : plumbing;;
|
2007-02-04 07:38:30 +00:00
|
|
|
prune) : plumbing;;
|
|
|
|
prune-packed) : plumbing;;
|
|
|
|
quiltimport) : import;;
|
2006-11-27 08:41:01 +00:00
|
|
|
read-tree) : plumbing;;
|
|
|
|
receive-pack) : plumbing;;
|
2010-01-22 10:54:51 +00:00
|
|
|
remote-*) : transport;;
|
2006-11-27 08:41:01 +00:00
|
|
|
rerere) : plumbing;;
|
|
|
|
rev-list) : plumbing;;
|
|
|
|
rev-parse) : plumbing;;
|
|
|
|
runstatus) : plumbing;;
|
|
|
|
sh-setup) : internal;;
|
|
|
|
shell) : daemon;;
|
2008-08-26 17:11:44 +00:00
|
|
|
show-ref) : plumbing;;
|
2006-11-27 08:41:01 +00:00
|
|
|
send-pack) : plumbing;;
|
|
|
|
show-index) : plumbing;;
|
|
|
|
ssh-*) : transport;;
|
|
|
|
stripspace) : plumbing;;
|
|
|
|
symbolic-ref) : plumbing;;
|
|
|
|
unpack-file) : plumbing;;
|
|
|
|
unpack-objects) : plumbing;;
|
2007-02-04 07:38:30 +00:00
|
|
|
update-index) : plumbing;;
|
2006-11-27 08:41:01 +00:00
|
|
|
update-ref) : plumbing;;
|
|
|
|
update-server-info) : daemon;;
|
|
|
|
upload-archive) : plumbing;;
|
|
|
|
upload-pack) : plumbing;;
|
|
|
|
write-tree) : plumbing;;
|
2008-08-26 17:11:44 +00:00
|
|
|
var) : infrequent;;
|
|
|
|
verify-pack) : infrequent;;
|
2007-02-04 07:38:30 +00:00
|
|
|
verify-tag) : plumbing;;
|
2006-11-27 08:41:01 +00:00
|
|
|
*) echo $i;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
}
|
2009-11-18 00:49:10 +00:00
|
|
|
|
|
|
|
__git_porcelain_commands=
|
|
|
|
__git_compute_porcelain_commands ()
|
|
|
|
{
|
2012-02-02 19:26:15 +00:00
|
|
|
test -n "$__git_porcelain_commands" ||
|
|
|
|
__git_porcelain_commands=$(__git_list_porcelain_commands)
|
2009-11-18 00:49:10 +00:00
|
|
|
}
|
2006-11-27 08:41:01 +00:00
|
|
|
|
2015-05-10 12:50:17 +00:00
|
|
|
# Lists all set config variables starting with the given section prefix,
|
|
|
|
# with the prefix removed.
|
|
|
|
__git_get_config_variables ()
|
2010-10-10 22:06:22 +00:00
|
|
|
{
|
2015-05-10 12:50:17 +00:00
|
|
|
local section="$1" i IFS=$'\n'
|
2015-08-10 09:46:07 +00:00
|
|
|
for i in $(git --git-dir="$(__gitdir)" config --name-only --get-regexp "^$section\..*" 2>/dev/null); do
|
|
|
|
echo "${i#$section.}"
|
2010-10-10 22:06:22 +00:00
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
__git_pretty_aliases ()
|
|
|
|
{
|
2015-05-10 12:50:17 +00:00
|
|
|
__git_get_config_variables "pretty"
|
2010-10-10 22:06:22 +00:00
|
|
|
}
|
|
|
|
|
2006-10-28 12:12:20 +00:00
|
|
|
__git_aliases ()
|
|
|
|
{
|
2015-05-10 12:50:17 +00:00
|
|
|
__git_get_config_variables "alias"
|
2006-10-28 12:12:20 +00:00
|
|
|
}
|
|
|
|
|
2009-01-15 16:02:23 +00:00
|
|
|
# __git_aliased_command requires 1 argument
|
2006-10-28 12:12:20 +00:00
|
|
|
__git_aliased_command ()
|
|
|
|
{
|
2006-11-05 11:21:57 +00:00
|
|
|
local word cmdline=$(git --git-dir="$(__gitdir)" \
|
2007-01-29 00:16:53 +00:00
|
|
|
config --get "alias.$1")
|
2006-10-28 12:12:20 +00:00
|
|
|
for word in $cmdline; do
|
bash: improve aliased command recognition
To support completion for aliases, the completion script tries to
figure out which git command is invoked by an alias. Its
implementation in __git_aliased_command() is rather straightforward:
it returns the first word from the alias. For simple aliases starting
with the git command (e.g. alias.last = cat-file commit HEAD) this
gives the right results. Unfortunately, it does not work with shell
command aliases, which can get rather complex, as illustrated by one
of Junio's aliases:
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
In this case the current implementation returns "!sh" as the aliased
git command, which is obviosly wrong.
The full parsing of a shell command alias like that in the completion
code is clearly unfeasible. However, we can easily improve on aliased
command recognition by eleminating stuff that is definitely not a git
command: shell commands (anything starting with '!'), command line
options (anything starting with '-'), environment variables (anything
with a '=' in it), and git itself. This way the above alias would be
handled correctly, and the completion script would correctly recognize
"log" as the aliased git command.
Of course, this solution is not perfect either, and could be fooled
easily. It's not hard to construct an alias, in which a word does not
match any of these filter patterns, but is still not a git command
(e.g. by setting an environment variable to a value which contains
spaces). It may even return false positives, when the output of a git
command is piped into an other git command, and the second gets the
command line options via $@, but options for the first one are
offered. However, the following patches will enable the user to
supply custom completion scripts for aliases, which can be used to
remedy these problematic cases.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:57 +00:00
|
|
|
case "$word" in
|
2010-02-23 21:03:00 +00:00
|
|
|
\!gitk|gitk)
|
|
|
|
echo "gitk"
|
2006-10-28 12:12:20 +00:00
|
|
|
return
|
2010-02-23 21:03:00 +00:00
|
|
|
;;
|
bash: improve aliased command recognition
To support completion for aliases, the completion script tries to
figure out which git command is invoked by an alias. Its
implementation in __git_aliased_command() is rather straightforward:
it returns the first word from the alias. For simple aliases starting
with the git command (e.g. alias.last = cat-file commit HEAD) this
gives the right results. Unfortunately, it does not work with shell
command aliases, which can get rather complex, as illustrated by one
of Junio's aliases:
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
In this case the current implementation returns "!sh" as the aliased
git command, which is obviosly wrong.
The full parsing of a shell command alias like that in the completion
code is clearly unfeasible. However, we can easily improve on aliased
command recognition by eleminating stuff that is definitely not a git
command: shell commands (anything starting with '!'), command line
options (anything starting with '-'), environment variables (anything
with a '=' in it), and git itself. This way the above alias would be
handled correctly, and the completion script would correctly recognize
"log" as the aliased git command.
Of course, this solution is not perfect either, and could be fooled
easily. It's not hard to construct an alias, in which a word does not
match any of these filter patterns, but is still not a git command
(e.g. by setting an environment variable to a value which contains
spaces). It may even return false positives, when the output of a git
command is piped into an other git command, and the second gets the
command line options via $@, but options for the first one are
offered. However, the following patches will enable the user to
supply custom completion scripts for aliases, which can be used to
remedy these problematic cases.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:57 +00:00
|
|
|
\!*) : shell command alias ;;
|
|
|
|
-*) : option ;;
|
|
|
|
*=*) : setting env ;;
|
|
|
|
git) : git itself ;;
|
2014-06-12 18:49:29 +00:00
|
|
|
\(\)) : skip parens of shell function definition ;;
|
|
|
|
{) : skip start of shell helper function ;;
|
|
|
|
:) : skip null command ;;
|
|
|
|
\'*) : skip opening quote after sh -c ;;
|
bash: improve aliased command recognition
To support completion for aliases, the completion script tries to
figure out which git command is invoked by an alias. Its
implementation in __git_aliased_command() is rather straightforward:
it returns the first word from the alias. For simple aliases starting
with the git command (e.g. alias.last = cat-file commit HEAD) this
gives the right results. Unfortunately, it does not work with shell
command aliases, which can get rather complex, as illustrated by one
of Junio's aliases:
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
In this case the current implementation returns "!sh" as the aliased
git command, which is obviosly wrong.
The full parsing of a shell command alias like that in the completion
code is clearly unfeasible. However, we can easily improve on aliased
command recognition by eleminating stuff that is definitely not a git
command: shell commands (anything starting with '!'), command line
options (anything starting with '-'), environment variables (anything
with a '=' in it), and git itself. This way the above alias would be
handled correctly, and the completion script would correctly recognize
"log" as the aliased git command.
Of course, this solution is not perfect either, and could be fooled
easily. It's not hard to construct an alias, in which a word does not
match any of these filter patterns, but is still not a git command
(e.g. by setting an environment variable to a value which contains
spaces). It may even return false positives, when the output of a git
command is piped into an other git command, and the second gets the
command line options via $@, but options for the first one are
offered. However, the following patches will enable the user to
supply custom completion scripts for aliases, which can be used to
remedy these problematic cases.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:57 +00:00
|
|
|
*)
|
|
|
|
echo "$word"
|
2006-10-28 12:12:20 +00:00
|
|
|
return
|
bash: improve aliased command recognition
To support completion for aliases, the completion script tries to
figure out which git command is invoked by an alias. Its
implementation in __git_aliased_command() is rather straightforward:
it returns the first word from the alias. For simple aliases starting
with the git command (e.g. alias.last = cat-file commit HEAD) this
gives the right results. Unfortunately, it does not work with shell
command aliases, which can get rather complex, as illustrated by one
of Junio's aliases:
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
In this case the current implementation returns "!sh" as the aliased
git command, which is obviosly wrong.
The full parsing of a shell command alias like that in the completion
code is clearly unfeasible. However, we can easily improve on aliased
command recognition by eleminating stuff that is definitely not a git
command: shell commands (anything starting with '!'), command line
options (anything starting with '-'), environment variables (anything
with a '=' in it), and git itself. This way the above alias would be
handled correctly, and the completion script would correctly recognize
"log" as the aliased git command.
Of course, this solution is not perfect either, and could be fooled
easily. It's not hard to construct an alias, in which a word does not
match any of these filter patterns, but is still not a git command
(e.g. by setting an environment variable to a value which contains
spaces). It may even return false positives, when the output of a git
command is piped into an other git command, and the second gets the
command line options via $@, but options for the first one are
offered. However, the following patches will enable the user to
supply custom completion scripts for aliases, which can be used to
remedy these problematic cases.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:57 +00:00
|
|
|
esac
|
2006-10-28 12:12:20 +00:00
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2009-09-15 10:21:43 +00:00
|
|
|
# __git_find_on_cmdline requires 1 argument
|
|
|
|
__git_find_on_cmdline ()
|
2008-03-10 15:02:23 +00:00
|
|
|
{
|
2011-04-28 16:01:52 +00:00
|
|
|
local word subcommand c=1
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
while [ $c -lt $cword ]; do
|
|
|
|
word="${words[c]}"
|
2008-03-10 15:02:23 +00:00
|
|
|
for subcommand in $1; do
|
|
|
|
if [ "$subcommand" = "$word" ]; then
|
|
|
|
echo "$subcommand"
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
done
|
2012-02-22 08:58:11 +00:00
|
|
|
((c++))
|
2008-03-10 15:02:23 +00:00
|
|
|
done
|
|
|
|
}
|
|
|
|
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
__git_has_doubledash ()
|
|
|
|
{
|
2011-04-28 16:01:52 +00:00
|
|
|
local c=1
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
while [ $c -lt $cword ]; do
|
|
|
|
if [ "--" = "${words[c]}" ]; then
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
return 0
|
|
|
|
fi
|
2012-02-22 08:58:11 +00:00
|
|
|
((c++))
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
done
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
# Try to count non option arguments passed on the command line for the
|
|
|
|
# specified git command.
|
|
|
|
# When options are used, it is necessary to use the special -- option to
|
|
|
|
# tell the implementation were non option arguments begin.
|
|
|
|
# XXX this can not be improved, since options can appear everywhere, as
|
|
|
|
# an example:
|
|
|
|
# git mv x -n y
|
|
|
|
#
|
|
|
|
# __git_count_arguments requires 1 argument: the git command executed.
|
|
|
|
__git_count_arguments ()
|
|
|
|
{
|
|
|
|
local word i c=0
|
|
|
|
|
|
|
|
# Skip "git" (first argument)
|
|
|
|
for ((i=1; i < ${#words[@]}; i++)); do
|
|
|
|
word="${words[i]}"
|
|
|
|
|
|
|
|
case "$word" in
|
|
|
|
--)
|
|
|
|
# Good; we can assume that the following are only non
|
|
|
|
# option arguments.
|
|
|
|
((c = 0))
|
|
|
|
;;
|
|
|
|
"$1")
|
|
|
|
# Skip the specified git command and discard git
|
|
|
|
# main options
|
|
|
|
((c = 0))
|
|
|
|
;;
|
|
|
|
?*)
|
|
|
|
((c++))
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
|
|
|
printf "%d" $c
|
|
|
|
}
|
|
|
|
|
2008-08-14 17:12:54 +00:00
|
|
|
__git_whitespacelist="nowarn warn error error-all fix"
|
2006-11-27 20:12:03 +00:00
|
|
|
|
|
|
|
_git_am ()
|
|
|
|
{
|
2011-04-28 16:01:52 +00:00
|
|
|
local dir="$(__gitdir)"
|
2008-07-21 10:51:02 +00:00
|
|
|
if [ -d "$dir"/rebase-apply ]; then
|
2010-02-12 14:11:47 +00:00
|
|
|
__gitcomp "--skip --continue --resolved --abort"
|
2006-11-27 20:12:03 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
case "$cur" in
|
|
|
|
--whitespace=*)
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
|
2006-11-27 20:12:03 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
--*)
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "
|
2009-04-05 16:33:38 +00:00
|
|
|
--3way --committer-date-is-author-date --ignore-date
|
2009-08-04 11:16:49 +00:00
|
|
|
--ignore-whitespace --ignore-space-change
|
2009-04-05 16:33:38 +00:00
|
|
|
--interactive --keep --no-utf8 --signoff --utf8
|
2009-10-07 08:48:50 +00:00
|
|
|
--whitespace= --scissors
|
2007-02-04 07:38:43 +00:00
|
|
|
"
|
2006-11-27 20:12:03 +00:00
|
|
|
return
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
|
|
|
_git_apply ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--whitespace=*)
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
|
2006-11-27 20:12:03 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
--*)
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "
|
2006-11-27 20:12:03 +00:00
|
|
|
--stat --numstat --summary --check --index
|
|
|
|
--cached --index-info --reverse --reject --unidiff-zero
|
|
|
|
--apply --no-add --exclude=
|
2009-08-04 11:16:49 +00:00
|
|
|
--ignore-whitespace --ignore-space-change
|
2006-11-27 20:12:03 +00:00
|
|
|
--whitespace= --inaccurate-eof --verbose
|
2007-02-04 07:38:43 +00:00
|
|
|
"
|
2006-11-27 20:12:03 +00:00
|
|
|
return
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2007-02-04 07:38:23 +00:00
|
|
|
_git_add ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
2008-06-14 09:48:01 +00:00
|
|
|
__gitcomp "
|
|
|
|
--interactive --refresh --patch --update --dry-run
|
2008-12-10 19:39:17 +00:00
|
|
|
--ignore-errors --intent-to-add
|
2008-06-14 09:48:01 +00:00
|
|
|
"
|
2007-02-04 07:38:23 +00:00
|
|
|
return
|
|
|
|
esac
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
# XXX should we check for --update and --all options ?
|
2013-09-18 17:06:08 +00:00
|
|
|
__git_complete_index_file "--others --modified --directory --no-empty-directory"
|
2007-02-04 07:38:23 +00:00
|
|
|
}
|
|
|
|
|
2008-08-05 05:50:36 +00:00
|
|
|
_git_archive ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--format=*)
|
|
|
|
__gitcomp "$(git archive --list)" "" "${cur##--format=}"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
--remote=*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)" "" "${cur##--remote=}"
|
2008-08-05 05:50:36 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--format= --list --verbose
|
|
|
|
--prefix= --remote= --exec=
|
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
__git_complete_file
|
|
|
|
}
|
|
|
|
|
2007-02-05 20:44:37 +00:00
|
|
|
_git_bisect ()
|
|
|
|
{
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2008-07-02 13:29:50 +00:00
|
|
|
local subcommands="start bad good skip reset visualize replay log run"
|
2009-09-15 10:21:43 +00:00
|
|
|
local subcommand="$(__git_find_on_cmdline "$subcommands")"
|
2008-03-10 15:02:23 +00:00
|
|
|
if [ -z "$subcommand" ]; then
|
2010-10-10 21:39:34 +00:00
|
|
|
if [ -f "$(__gitdir)"/BISECT_START ]; then
|
|
|
|
__gitcomp "$subcommands"
|
|
|
|
else
|
|
|
|
__gitcomp "replay start"
|
|
|
|
fi
|
2007-02-05 20:44:37 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2008-03-10 15:02:23 +00:00
|
|
|
case "$subcommand" in
|
2010-10-10 21:39:33 +00:00
|
|
|
bad|good|reset|skip|start)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2007-02-05 20:44:37 +00:00
|
|
|
;;
|
|
|
|
*)
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_branch ()
|
|
|
|
{
|
2011-04-28 16:01:52 +00:00
|
|
|
local i c=1 only_local_ref="n" has_r="n"
|
2008-03-04 18:00:59 +00:00
|
|
|
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
while [ $c -lt $cword ]; do
|
|
|
|
i="${words[c]}"
|
2008-03-04 18:00:59 +00:00
|
|
|
case "$i" in
|
|
|
|
-d|-m) only_local_ref="y" ;;
|
|
|
|
-r) has_r="y" ;;
|
|
|
|
esac
|
2012-02-22 08:58:11 +00:00
|
|
|
((c++))
|
2008-03-04 18:00:59 +00:00
|
|
|
done
|
|
|
|
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
case "$cur" in
|
2012-09-11 11:58:30 +00:00
|
|
|
--set-upstream-to=*)
|
2015-03-22 12:03:11 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "" "${cur##--set-upstream-to=}"
|
2012-09-11 11:58:30 +00:00
|
|
|
;;
|
2008-03-04 18:00:58 +00:00
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--color --no-color --verbose --abbrev= --no-abbrev
|
2008-07-07 20:41:54 +00:00
|
|
|
--track --no-track --contains --merged --no-merged
|
2012-09-01 15:13:10 +00:00
|
|
|
--set-upstream-to= --edit-description --list
|
|
|
|
--unset-upstream
|
2008-03-04 18:00:58 +00:00
|
|
|
"
|
|
|
|
;;
|
2008-03-04 18:00:59 +00:00
|
|
|
*)
|
|
|
|
if [ $only_local_ref = "y" -a $has_r = "n" ]; then
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_heads)"
|
2008-03-04 18:00:59 +00:00
|
|
|
else
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2008-03-04 18:00:59 +00:00
|
|
|
fi
|
|
|
|
;;
|
2008-03-04 18:00:58 +00:00
|
|
|
esac
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2007-08-12 18:46:12 +00:00
|
|
|
_git_bundle ()
|
|
|
|
{
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
local cmd="${words[2]}"
|
|
|
|
case "$cword" in
|
2008-11-27 13:35:38 +00:00
|
|
|
2)
|
2007-08-12 18:46:12 +00:00
|
|
|
__gitcomp "create list-heads verify unbundle"
|
|
|
|
;;
|
2008-11-27 13:35:38 +00:00
|
|
|
3)
|
2007-08-12 18:46:12 +00:00
|
|
|
# looking for a file
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
case "$cmd" in
|
|
|
|
create)
|
|
|
|
__git_complete_revlist
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_checkout ()
|
|
|
|
{
|
2008-07-23 11:49:22 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2009-09-24 12:23:15 +00:00
|
|
|
case "$cur" in
|
|
|
|
--conflict=*)
|
|
|
|
__gitcomp "diff3 merge" "" "${cur##--conflict=}"
|
|
|
|
;;
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--quiet --ours --theirs --track --no-track --merge
|
2010-05-22 00:43:52 +00:00
|
|
|
--conflict= --orphan --patch
|
2009-09-24 12:23:15 +00:00
|
|
|
"
|
|
|
|
;;
|
|
|
|
*)
|
2010-10-12 21:38:12 +00:00
|
|
|
# check if --track, --no-track, or --no-guess was specified
|
|
|
|
# if so, disable DWIM mode
|
|
|
|
local flags="--track --no-track --no-guess" track=1
|
|
|
|
if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
|
|
|
|
track=''
|
|
|
|
fi
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs '' $track)"
|
2009-09-24 12:23:15 +00:00
|
|
|
;;
|
|
|
|
esac
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2007-02-05 20:44:22 +00:00
|
|
|
_git_cherry ()
|
|
|
|
{
|
2015-03-22 12:03:11 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2007-02-05 20:44:22 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 08:41:59 +00:00
|
|
|
_git_cherry_pick ()
|
|
|
|
{
|
2013-04-10 09:08:18 +00:00
|
|
|
local dir="$(__gitdir)"
|
|
|
|
if [ -f "$dir"/CHERRY_PICK_HEAD ]; then
|
|
|
|
__gitcomp "--continue --quit --abort"
|
|
|
|
return
|
|
|
|
fi
|
2006-11-27 08:41:59 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
2013-04-10 09:08:18 +00:00
|
|
|
__gitcomp "--edit --no-commit --signoff --strategy= --mainline"
|
2006-11-27 08:41:59 +00:00
|
|
|
;;
|
|
|
|
*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2006-11-27 08:41:59 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2008-08-05 05:50:32 +00:00
|
|
|
_git_clean ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--dry-run --quiet"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
# XXX should we check for -x option ?
|
2013-09-18 17:06:08 +00:00
|
|
|
__git_complete_index_file "--others --directory"
|
2008-08-05 05:50:32 +00:00
|
|
|
}
|
|
|
|
|
2008-08-05 05:50:31 +00:00
|
|
|
_git_clone ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--local
|
|
|
|
--no-hardlinks
|
|
|
|
--shared
|
|
|
|
--reference
|
|
|
|
--quiet
|
|
|
|
--no-checkout
|
|
|
|
--bare
|
|
|
|
--mirror
|
|
|
|
--origin
|
|
|
|
--upload-pack
|
|
|
|
--template=
|
|
|
|
--depth
|
2012-11-28 18:27:02 +00:00
|
|
|
--single-branch
|
|
|
|
--branch
|
2008-08-05 05:50:31 +00:00
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2006-11-28 17:12:08 +00:00
|
|
|
_git_commit ()
|
|
|
|
{
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
case "$prev" in
|
|
|
|
-c|-C)
|
|
|
|
__gitcomp_nl "$(__git_refs)" "" "${cur}"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
|
2006-11-28 17:12:08 +00:00
|
|
|
case "$cur" in
|
2009-12-05 00:51:41 +00:00
|
|
|
--cleanup=*)
|
2015-06-08 01:43:31 +00:00
|
|
|
__gitcomp "default scissors strip verbatim whitespace
|
2009-12-05 00:51:41 +00:00
|
|
|
" "" "${cur##--cleanup=}"
|
|
|
|
return
|
|
|
|
;;
|
2011-10-06 18:40:30 +00:00
|
|
|
--reuse-message=*|--reedit-message=*|\
|
|
|
|
--fixup=*|--squash=*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "" "${cur#*=}"
|
2009-12-05 00:51:41 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
--untracked-files=*)
|
|
|
|
__gitcomp "all no normal" "" "${cur##--untracked-files=}"
|
|
|
|
return
|
|
|
|
;;
|
2006-11-28 17:12:08 +00:00
|
|
|
--*)
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "
|
2006-11-28 17:12:08 +00:00
|
|
|
--all --author= --signoff --verify --no-verify
|
2012-09-16 16:06:11 +00:00
|
|
|
--edit --no-edit
|
|
|
|
--amend --include --only --interactive
|
2009-12-05 00:51:41 +00:00
|
|
|
--dry-run --reuse-message= --reedit-message=
|
|
|
|
--reset-author --file= --message= --template=
|
|
|
|
--cleanup= --untracked-files --untracked-files=
|
2011-10-06 18:40:30 +00:00
|
|
|
--verbose --quiet --fixup= --squash=
|
2007-02-04 07:38:43 +00:00
|
|
|
"
|
2006-11-28 17:12:08 +00:00
|
|
|
return
|
|
|
|
esac
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
if git rev-parse --verify --quiet HEAD >/dev/null; then
|
2013-04-27 20:10:03 +00:00
|
|
|
__git_complete_index_file "--committable"
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
else
|
|
|
|
# This is the first commit
|
|
|
|
__git_complete_index_file "--cached"
|
|
|
|
fi
|
2006-11-28 17:12:08 +00:00
|
|
|
}
|
|
|
|
|
2007-08-23 05:42:11 +00:00
|
|
|
_git_describe ()
|
|
|
|
{
|
2008-07-26 10:26:56 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--all --tags --contains --abbrev= --candidates=
|
|
|
|
--exact-match --debug --long --match --always
|
|
|
|
"
|
|
|
|
return
|
|
|
|
esac
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2007-08-23 05:42:11 +00:00
|
|
|
}
|
|
|
|
|
2013-01-16 07:51:58 +00:00
|
|
|
__git_diff_algorithms="myers minimal patience histogram"
|
|
|
|
|
2009-01-19 21:18:00 +00:00
|
|
|
__git_diff_common_options="--stat --numstat --shortstat --summary
|
2007-11-23 01:11:35 +00:00
|
|
|
--patch-with-stat --name-only --name-status --color
|
|
|
|
--no-color --color-words --no-renames --check
|
2008-08-22 17:25:06 +00:00
|
|
|
--full-index --binary --abbrev --diff-filter=
|
2009-01-19 21:17:59 +00:00
|
|
|
--find-copies-harder
|
2007-11-23 01:11:35 +00:00
|
|
|
--text --ignore-space-at-eol --ignore-space-change
|
2014-09-03 15:00:41 +00:00
|
|
|
--ignore-all-space --ignore-blank-lines --exit-code
|
|
|
|
--quiet --ext-diff --no-ext-diff
|
2008-04-06 16:56:08 +00:00
|
|
|
--no-prefix --src-prefix= --dst-prefix=
|
2008-12-28 18:45:32 +00:00
|
|
|
--inter-hunk-context=
|
2013-01-12 16:02:13 +00:00
|
|
|
--patience --histogram --minimal
|
2013-06-18 19:24:05 +00:00
|
|
|
--raw --word-diff
|
2009-10-07 08:48:51 +00:00
|
|
|
--dirstat --dirstat= --dirstat-by-file
|
|
|
|
--dirstat-by-file= --cumulative
|
2013-01-16 07:51:58 +00:00
|
|
|
--diff-algorithm=
|
2009-01-19 21:18:00 +00:00
|
|
|
"
|
|
|
|
|
|
|
|
_git_diff ()
|
|
|
|
{
|
|
|
|
__git_has_doubledash && return
|
|
|
|
|
|
|
|
case "$cur" in
|
2013-01-16 07:51:58 +00:00
|
|
|
--diff-algorithm=*)
|
|
|
|
__gitcomp "$__git_diff_algorithms" "" "${cur##--diff-algorithm=}"
|
|
|
|
return
|
|
|
|
;;
|
2009-01-19 21:18:00 +00:00
|
|
|
--*)
|
2009-03-21 23:29:27 +00:00
|
|
|
__gitcomp "--cached --staged --pickaxe-all --pickaxe-regex
|
2010-09-23 12:33:51 +00:00
|
|
|
--base --ours --theirs --no-index
|
2009-01-19 21:18:00 +00:00
|
|
|
$__git_diff_common_options
|
2008-04-06 16:56:08 +00:00
|
|
|
"
|
2007-11-23 01:11:35 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
bash: complete 'git diff ...branc<TAB>'
While doing a final sanity check before merging a topic Bsomething, it
is a good idea to review what damage Bsomething branch would make, by
running:
$ git diff ...Bsomething
Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'. This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'<tree>:<path>' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'. Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support '<tree>:<path>'.
To support both '...<ref>' and '<tree>:<path>' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file(). The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.
This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 18:12:29 +00:00
|
|
|
__git_complete_revlist_file
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 22:29:35 +00:00
|
|
|
__git_mergetools_common="diffuse diffmerge ecmerge emerge kdiff3 meld opendiff
|
2014-10-20 22:49:36 +00:00
|
|
|
tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc codecompare
|
2009-04-06 08:31:27 +00:00
|
|
|
"
|
|
|
|
|
|
|
|
_git_difftool ()
|
|
|
|
{
|
2009-10-28 09:45:38 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2009-04-06 08:31:27 +00:00
|
|
|
case "$cur" in
|
|
|
|
--tool=*)
|
|
|
|
__gitcomp "$__git_mergetools_common kompare" "" "${cur##--tool=}"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
--*)
|
2009-10-28 09:45:38 +00:00
|
|
|
__gitcomp "--cached --staged --pickaxe-all --pickaxe-regex
|
|
|
|
--base --ours --theirs
|
|
|
|
--no-renames --diff-filter= --find-copies-harder
|
|
|
|
--relative --ignore-submodules
|
|
|
|
--tool="
|
2009-04-06 08:31:27 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2013-06-02 14:03:41 +00:00
|
|
|
__git_complete_revlist_file
|
2009-04-06 08:31:27 +00:00
|
|
|
}
|
|
|
|
|
2014-02-09 14:35:31 +00:00
|
|
|
__git_fetch_recurse_submodules="yes on-demand no"
|
|
|
|
|
2009-03-06 04:39:33 +00:00
|
|
|
__git_fetch_options="
|
|
|
|
--quiet --verbose --append --upload-pack --force --keep --depth=
|
2014-02-09 14:35:31 +00:00
|
|
|
--tags --no-tags --all --prune --dry-run --recurse-submodules=
|
2009-03-06 04:39:33 +00:00
|
|
|
"
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_fetch ()
|
|
|
|
{
|
2009-03-06 04:39:33 +00:00
|
|
|
case "$cur" in
|
2014-02-09 14:35:31 +00:00
|
|
|
--recurse-submodules=*)
|
|
|
|
__gitcomp "$__git_fetch_recurse_submodules" "" "${cur##--recurse-submodules=}"
|
|
|
|
return
|
|
|
|
;;
|
2009-03-06 04:39:33 +00:00
|
|
|
--*)
|
|
|
|
__gitcomp "$__git_fetch_options"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2009-03-06 04:39:31 +00:00
|
|
|
__git_complete_remote_or_refspec
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2012-10-16 00:21:50 +00:00
|
|
|
__git_format_patch_options="
|
2013-04-27 20:17:44 +00:00
|
|
|
--stdout --attach --no-attach --thread --thread= --no-thread
|
2012-10-16 00:21:50 +00:00
|
|
|
--numbered --start-number --numbered-files --keep-subject --signoff
|
|
|
|
--signature --no-signature --in-reply-to= --cc= --full-index --binary
|
|
|
|
--not --all --cover-letter --no-prefix --src-prefix= --dst-prefix=
|
|
|
|
--inline --suffix= --ignore-if-in-upstream --subject-prefix=
|
2013-04-27 20:17:44 +00:00
|
|
|
--output-directory --reroll-count --to= --quiet --notes
|
2012-10-16 00:21:50 +00:00
|
|
|
"
|
|
|
|
|
2006-11-27 08:41:43 +00:00
|
|
|
_git_format_patch ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
2009-03-23 10:26:51 +00:00
|
|
|
--thread=*)
|
|
|
|
__gitcomp "
|
|
|
|
deep shallow
|
|
|
|
" "" "${cur##--thread=}"
|
|
|
|
return
|
|
|
|
;;
|
2006-11-27 08:41:43 +00:00
|
|
|
--*)
|
2012-10-16 00:21:50 +00:00
|
|
|
__gitcomp "$__git_format_patch_options"
|
2006-11-27 08:41:43 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
__git_complete_revlist
|
|
|
|
}
|
|
|
|
|
2009-03-22 18:49:07 +00:00
|
|
|
_git_fsck ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--tags --root --unreachable --cache --no-reflogs --full
|
|
|
|
--strict --verbose --lost-found
|
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2007-02-05 20:44:28 +00:00
|
|
|
_git_gc ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
2007-08-23 05:39:22 +00:00
|
|
|
__gitcomp "--prune --aggressive"
|
2007-02-05 20:44:28 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2010-02-23 21:03:00 +00:00
|
|
|
_git_gitk ()
|
|
|
|
{
|
|
|
|
_gitk
|
|
|
|
}
|
|
|
|
|
2011-10-21 17:30:21 +00:00
|
|
|
__git_match_ctag() {
|
2015-03-14 13:40:39 +00:00
|
|
|
awk "/^${1//\//\\/}/ { print \$1 }" "$2"
|
2011-10-21 17:30:21 +00:00
|
|
|
}
|
|
|
|
|
2008-08-02 00:56:33 +00:00
|
|
|
_git_grep ()
|
|
|
|
{
|
|
|
|
__git_has_doubledash && return
|
|
|
|
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--cached
|
|
|
|
--text --ignore-case --word-regexp --invert-match
|
2011-05-04 22:00:18 +00:00
|
|
|
--full-name --line-number
|
2008-08-02 00:56:33 +00:00
|
|
|
--extended-regexp --basic-regexp --fixed-strings
|
2011-05-09 21:52:05 +00:00
|
|
|
--perl-regexp
|
2008-08-02 00:56:33 +00:00
|
|
|
--files-with-matches --name-only
|
|
|
|
--files-without-match
|
grep: Add --max-depth option.
It is useful to grep directories non-recursively, e.g. when one wants to
look for all files in the toplevel directory, but not in any subdirectory,
or in Documentation/, but not in Documentation/technical/.
This patch adds support for --max-depth <depth> option to git-grep. If it is
given, git-grep descends at most <depth> levels of directories below paths
specified on the command line.
Note that if path specified on command line contains wildcards, this option
makes no sense, e.g.
$ git grep -l --max-depth 0 GNU -- 'contrib/*'
(note the quotes) will search all files in contrib/, even in
subdirectories, because '*' matches all files.
Documentation updates, bash-completion and simple test cases are also
provided.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22 17:52:15 +00:00
|
|
|
--max-depth
|
2008-08-02 00:56:33 +00:00
|
|
|
--count
|
|
|
|
--and --or --not --all-match
|
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2009-10-12 09:00:09 +00:00
|
|
|
|
2011-10-21 17:30:21 +00:00
|
|
|
case "$cword,$prev" in
|
|
|
|
2,*|*,-*)
|
|
|
|
if test -r tags; then
|
2011-12-09 21:37:18 +00:00
|
|
|
__gitcomp_nl "$(__git_match_ctag "$cur" tags)"
|
2011-10-21 17:30:21 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2008-08-02 00:56:33 +00:00
|
|
|
}
|
|
|
|
|
2008-07-24 00:07:23 +00:00
|
|
|
_git_help ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--all --info --man --web"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_compute_all_commands
|
2011-03-21 09:25:06 +00:00
|
|
|
__gitcomp "$__git_all_commands $(__git_aliases)
|
2008-08-15 17:59:28 +00:00
|
|
|
attributes cli core-tutorial cvs-migration
|
|
|
|
diffcore gitk glossary hooks ignore modules
|
2011-07-08 23:14:10 +00:00
|
|
|
namespaces repository-layout tutorial tutorial-2
|
2008-10-20 17:31:38 +00:00
|
|
|
workflows
|
2008-08-15 17:59:28 +00:00
|
|
|
"
|
2008-07-24 00:07:23 +00:00
|
|
|
}
|
|
|
|
|
2008-08-05 05:50:33 +00:00
|
|
|
_git_init ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--shared=*)
|
|
|
|
__gitcomp "
|
|
|
|
false true umask group all world everybody
|
|
|
|
" "" "${cur##--shared=}"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
--*)
|
|
|
|
__gitcomp "--quiet --bare --template= --shared --shared="
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2008-08-05 05:50:37 +00:00
|
|
|
_git_ls_files ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--cached --deleted --modified --others --ignored
|
|
|
|
--stage --directory --no-empty-directory --unmerged
|
|
|
|
--killed --exclude= --exclude-from=
|
|
|
|
--exclude-per-directory= --exclude-standard
|
|
|
|
--error-unmatch --with-tree= --full-name
|
|
|
|
--abbrev --ignored --exclude-per-directory
|
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
# XXX ignore options like --modified and always suggest all cached
|
|
|
|
# files.
|
|
|
|
__git_complete_index_file "--cached"
|
2008-08-05 05:50:37 +00:00
|
|
|
}
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_ls_remote ()
|
|
|
|
{
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)"
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
_git_ls_tree ()
|
|
|
|
{
|
|
|
|
__git_complete_file
|
|
|
|
}
|
|
|
|
|
2009-02-16 16:34:56 +00:00
|
|
|
# Options that go well for log, shortlog and gitk
|
|
|
|
__git_log_common_options="
|
|
|
|
--not --all
|
|
|
|
--branches --tags --remotes
|
2009-07-13 15:11:45 +00:00
|
|
|
--first-parent --merges --no-merges
|
2009-02-16 16:34:56 +00:00
|
|
|
--max-count=
|
|
|
|
--max-age= --since= --after=
|
|
|
|
--min-age= --until= --before=
|
2011-03-23 09:38:51 +00:00
|
|
|
--min-parents= --max-parents=
|
|
|
|
--no-min-parents --no-max-parents
|
2009-02-16 16:34:56 +00:00
|
|
|
"
|
|
|
|
# Options that go well for log and gitk (not shortlog)
|
|
|
|
__git_log_gitk_options="
|
|
|
|
--dense --sparse --full-history
|
|
|
|
--simplify-merges --simplify-by-decoration
|
2011-04-14 17:53:13 +00:00
|
|
|
--left-right --notes --no-notes
|
2009-02-16 16:34:56 +00:00
|
|
|
"
|
|
|
|
# Options that go well for log and shortlog (not gitk)
|
|
|
|
__git_log_shortlog_options="
|
|
|
|
--author= --committer= --grep=
|
log: teach --invert-grep option
"git log --grep=<string>" shows only commits with messages that
match the given string, but sometimes it is useful to be able to
show only commits that do *not* have certain messages (e.g. "show
me ones that are not FIXUP commits").
Originally, we had the invert-grep flag in grep_opt, but because
"git grep --invert-grep" does not make sense except in conjunction
with "--files-with-matches", which is already covered by
"--files-without-matches", it was moved it to revisions structure.
To have the flag there expresses the function to the feature better.
When the newly inserted two tests run, the history would have commits
with messages "initial", "second", "third", "fourth", "fifth", "sixth"
and "Second", committed in this order. The commits that does not match
either "th" or "Sec" is "second" and "initial". For the case insensitive
case only "initial" matches.
Signed-off-by: Christoph Junghans <ottxor@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-13 01:33:32 +00:00
|
|
|
--all-match --invert-grep
|
2009-02-16 16:34:56 +00:00
|
|
|
"
|
|
|
|
|
2009-01-16 16:02:15 +00:00
|
|
|
__git_log_pretty_formats="oneline short medium full fuller email raw format:"
|
2009-05-04 06:25:34 +00:00
|
|
|
__git_log_date_formats="relative iso8601 rfc2822 short local default raw"
|
2009-01-16 16:02:15 +00:00
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_log ()
|
|
|
|
{
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2009-02-16 16:34:57 +00:00
|
|
|
local g="$(git rev-parse --git-dir 2>/dev/null)"
|
|
|
|
local merge=""
|
2009-03-30 11:27:37 +00:00
|
|
|
if [ -f "$g/MERGE_HEAD" ]; then
|
2009-02-16 16:34:57 +00:00
|
|
|
merge="--merge"
|
|
|
|
fi
|
2006-11-27 08:42:18 +00:00
|
|
|
case "$cur" in
|
2011-10-08 01:09:34 +00:00
|
|
|
--pretty=*|--format=*)
|
2010-10-10 22:06:22 +00:00
|
|
|
__gitcomp "$__git_log_pretty_formats $(__git_pretty_aliases)
|
2011-10-08 01:09:34 +00:00
|
|
|
" "" "${cur#*=}"
|
2009-02-24 13:33:29 +00:00
|
|
|
return
|
|
|
|
;;
|
2007-08-23 05:39:22 +00:00
|
|
|
--date=*)
|
2009-05-04 06:25:34 +00:00
|
|
|
__gitcomp "$__git_log_date_formats" "" "${cur##--date=}"
|
2007-08-23 05:39:22 +00:00
|
|
|
return
|
|
|
|
;;
|
2009-10-07 08:48:50 +00:00
|
|
|
--decorate=*)
|
2015-05-01 17:21:00 +00:00
|
|
|
__gitcomp "full short no" "" "${cur##--decorate=}"
|
2009-10-07 08:48:50 +00:00
|
|
|
return
|
|
|
|
;;
|
2006-11-27 08:42:18 +00:00
|
|
|
--*)
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "
|
2009-02-16 16:34:56 +00:00
|
|
|
$__git_log_common_options
|
|
|
|
$__git_log_shortlog_options
|
|
|
|
$__git_log_gitk_options
|
2007-05-24 05:51:30 +00:00
|
|
|
--root --topo-order --date-order --reverse
|
2009-06-03 20:20:58 +00:00
|
|
|
--follow --full-diff
|
2006-11-27 08:42:18 +00:00
|
|
|
--abbrev-commit --abbrev=
|
2007-08-23 05:39:22 +00:00
|
|
|
--relative-date --date=
|
2009-02-24 13:33:29 +00:00
|
|
|
--pretty= --format= --oneline
|
2014-10-04 23:20:38 +00:00
|
|
|
--show-signature
|
2009-02-16 16:34:56 +00:00
|
|
|
--cherry-pick
|
2008-06-19 21:15:53 +00:00
|
|
|
--graph
|
2009-10-07 08:48:50 +00:00
|
|
|
--decorate --decorate=
|
2009-01-19 21:18:00 +00:00
|
|
|
--walk-reflogs
|
2009-02-16 16:34:56 +00:00
|
|
|
--parents --children
|
2009-02-16 16:34:57 +00:00
|
|
|
$merge
|
2009-01-19 21:18:00 +00:00
|
|
|
$__git_diff_common_options
|
2009-01-19 21:17:59 +00:00
|
|
|
--pickaxe-all --pickaxe-regex
|
2007-02-04 07:38:43 +00:00
|
|
|
"
|
2006-11-27 08:42:18 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2006-11-27 08:41:43 +00:00
|
|
|
__git_complete_revlist
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2014-05-22 13:58:37 +00:00
|
|
|
# Common merge options shared by git-merge(1) and git-pull(1).
|
2009-03-06 04:39:33 +00:00
|
|
|
__git_merge_options="
|
|
|
|
--no-commit --no-stat --log --no-log --squash --strategy
|
2012-01-30 19:29:33 +00:00
|
|
|
--commit --stat --no-squash --ff --no-ff --ff-only --edit --no-edit
|
2014-05-22 13:58:38 +00:00
|
|
|
--verify-signatures --no-verify-signatures --gpg-sign
|
|
|
|
--quiet --verbose --progress --no-progress
|
2009-03-06 04:39:33 +00:00
|
|
|
"
|
|
|
|
|
2006-11-27 08:40:47 +00:00
|
|
|
_git_merge ()
|
|
|
|
{
|
2009-03-06 16:30:44 +00:00
|
|
|
__git_complete_strategy && return
|
|
|
|
|
2006-11-27 08:40:47 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
2014-05-22 13:58:38 +00:00
|
|
|
__gitcomp "$__git_merge_options
|
|
|
|
--rerere-autoupdate --no-rerere-autoupdate --abort"
|
2006-11-27 08:40:47 +00:00
|
|
|
return
|
|
|
|
esac
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2006-11-27 08:40:47 +00:00
|
|
|
}
|
|
|
|
|
2008-08-14 22:41:10 +00:00
|
|
|
_git_mergetool ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--tool=*)
|
2009-04-06 08:31:27 +00:00
|
|
|
__gitcomp "$__git_mergetools_common tortoisemerge" "" "${cur##--tool=}"
|
2008-08-14 22:41:10 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
--*)
|
|
|
|
__gitcomp "--tool="
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_merge_base ()
|
|
|
|
{
|
2014-01-11 14:27:12 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--octopus --independent --is-ancestor --fork-point"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2008-08-05 05:50:38 +00:00
|
|
|
_git_mv ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--dry-run"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
if [ $(__git_count_arguments "mv") -gt 0 ]; then
|
|
|
|
# We need to show both cached and untracked files (including
|
|
|
|
# empty directories) since this may not be the last argument.
|
|
|
|
__git_complete_index_file "--cached --others --directory"
|
|
|
|
else
|
|
|
|
__git_complete_index_file "--cached"
|
|
|
|
fi
|
2008-08-05 05:50:38 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 08:41:12 +00:00
|
|
|
_git_name_rev ()
|
|
|
|
{
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "--tags --all --stdin"
|
2006-11-27 08:41:12 +00:00
|
|
|
}
|
|
|
|
|
2010-01-28 01:05:55 +00:00
|
|
|
_git_notes ()
|
|
|
|
{
|
2010-10-10 21:43:33 +00:00
|
|
|
local subcommands='add append copy edit list prune remove show'
|
|
|
|
local subcommand="$(__git_find_on_cmdline "$subcommands")"
|
2010-01-28 01:05:55 +00:00
|
|
|
|
2010-10-10 21:43:33 +00:00
|
|
|
case "$subcommand,$cur" in
|
|
|
|
,--*)
|
|
|
|
__gitcomp '--ref'
|
|
|
|
;;
|
|
|
|
,*)
|
2012-04-15 19:44:17 +00:00
|
|
|
case "$prev" in
|
2010-10-10 21:43:33 +00:00
|
|
|
--ref)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2010-10-10 21:43:33 +00:00
|
|
|
;;
|
|
|
|
*)
|
|
|
|
__gitcomp "$subcommands --ref"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
;;
|
2011-10-08 01:06:34 +00:00
|
|
|
add,--reuse-message=*|append,--reuse-message=*|\
|
2010-10-10 21:43:33 +00:00
|
|
|
add,--reedit-message=*|append,--reedit-message=*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)" "" "${cur#*=}"
|
2010-10-10 21:43:33 +00:00
|
|
|
;;
|
|
|
|
add,--*|append,--*)
|
|
|
|
__gitcomp '--file= --message= --reedit-message=
|
|
|
|
--reuse-message='
|
|
|
|
;;
|
|
|
|
copy,--*)
|
|
|
|
__gitcomp '--stdin'
|
|
|
|
;;
|
|
|
|
prune,--*)
|
|
|
|
__gitcomp '--dry-run --verbose'
|
|
|
|
;;
|
|
|
|
prune,*)
|
2010-01-28 01:05:55 +00:00
|
|
|
;;
|
|
|
|
*)
|
2012-04-15 19:44:17 +00:00
|
|
|
case "$prev" in
|
2010-10-10 21:43:33 +00:00
|
|
|
-m|-F)
|
|
|
|
;;
|
|
|
|
*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2010-10-10 21:43:33 +00:00
|
|
|
;;
|
|
|
|
esac
|
2010-01-28 01:05:55 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_pull ()
|
|
|
|
{
|
2009-03-06 04:39:33 +00:00
|
|
|
__git_complete_strategy && return
|
|
|
|
|
|
|
|
case "$cur" in
|
2014-02-09 14:35:31 +00:00
|
|
|
--recurse-submodules=*)
|
|
|
|
__gitcomp "$__git_fetch_recurse_submodules" "" "${cur##--recurse-submodules=}"
|
|
|
|
return
|
|
|
|
;;
|
2009-03-06 04:39:33 +00:00
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--rebase --no-rebase
|
|
|
|
$__git_merge_options
|
|
|
|
$__git_fetch_options
|
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2009-03-06 04:39:31 +00:00
|
|
|
__git_complete_remote_or_refspec
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2014-02-09 14:35:31 +00:00
|
|
|
__git_push_recurse_submodules="check on-demand"
|
|
|
|
|
2014-07-22 18:24:58 +00:00
|
|
|
__git_complete_force_with_lease ()
|
|
|
|
{
|
|
|
|
local cur_=$1
|
|
|
|
|
|
|
|
case "$cur_" in
|
|
|
|
--*=)
|
|
|
|
;;
|
|
|
|
*:*)
|
|
|
|
__gitcomp_nl "$(__git_refs)" "" "${cur_#*:}"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
__gitcomp_nl "$(__git_refs)" "" "$cur_"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2006-09-28 09:31:25 +00:00
|
|
|
_git_push ()
|
|
|
|
{
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
case "$prev" in
|
2009-03-06 04:39:33 +00:00
|
|
|
--repo)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)"
|
2009-03-06 04:39:33 +00:00
|
|
|
return
|
2014-07-22 18:24:56 +00:00
|
|
|
;;
|
|
|
|
--recurse-submodules)
|
|
|
|
__gitcomp "$__git_push_recurse_submodules"
|
|
|
|
return
|
|
|
|
;;
|
2009-03-06 04:39:33 +00:00
|
|
|
esac
|
|
|
|
case "$cur" in
|
|
|
|
--repo=*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)" "" "${cur##--repo=}"
|
2009-03-06 04:39:33 +00:00
|
|
|
return
|
|
|
|
;;
|
2014-02-09 14:35:31 +00:00
|
|
|
--recurse-submodules=*)
|
|
|
|
__gitcomp "$__git_push_recurse_submodules" "" "${cur##--recurse-submodules=}"
|
|
|
|
return
|
|
|
|
;;
|
2014-07-22 18:24:58 +00:00
|
|
|
--force-with-lease=*)
|
|
|
|
__git_complete_force_with_lease "${cur##--force-with-lease=}"
|
|
|
|
return
|
|
|
|
;;
|
2009-03-06 04:39:33 +00:00
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--all --mirror --tags --dry-run --force --verbose
|
2014-07-22 18:24:57 +00:00
|
|
|
--quiet --prune --delete --follow-tags
|
2011-10-06 18:40:31 +00:00
|
|
|
--receive-pack= --repo= --set-upstream
|
2014-07-22 18:24:58 +00:00
|
|
|
--force-with-lease --force-with-lease= --recurse-submodules=
|
2009-03-06 04:39:33 +00:00
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2009-03-06 04:39:31 +00:00
|
|
|
__git_complete_remote_or_refspec
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 08:42:07 +00:00
|
|
|
_git_rebase ()
|
|
|
|
{
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
local dir="$(__gitdir)"
|
2015-08-05 13:40:00 +00:00
|
|
|
if [ -f "$dir"/rebase-merge/interactive ]; then
|
|
|
|
__gitcomp "--continue --skip --abort --edit-todo"
|
|
|
|
return
|
|
|
|
elif [ -d "$dir"/rebase-apply ] || [ -d "$dir"/rebase-merge ]; then
|
2007-02-04 07:38:43 +00:00
|
|
|
__gitcomp "--continue --skip --abort"
|
2006-11-27 08:42:07 +00:00
|
|
|
return
|
|
|
|
fi
|
2009-03-06 16:30:44 +00:00
|
|
|
__git_complete_strategy && return
|
2006-11-27 08:42:07 +00:00
|
|
|
case "$cur" in
|
2009-10-17 09:33:38 +00:00
|
|
|
--whitespace=*)
|
|
|
|
__gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
|
|
|
|
return
|
|
|
|
;;
|
2006-11-27 08:42:07 +00:00
|
|
|
--*)
|
2009-10-17 09:33:38 +00:00
|
|
|
__gitcomp "
|
|
|
|
--onto --merge --strategy --interactive
|
|
|
|
--preserve-merges --stat --no-stat
|
|
|
|
--committer-date-is-author-date --ignore-date
|
|
|
|
--ignore-whitespace --whitespace=
|
2014-01-11 14:27:13 +00:00
|
|
|
--autosquash --fork-point --no-fork-point
|
2015-01-07 12:40:31 +00:00
|
|
|
--autostash
|
2009-10-17 09:33:38 +00:00
|
|
|
"
|
|
|
|
|
2006-11-27 08:42:07 +00:00
|
|
|
return
|
|
|
|
esac
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2006-11-27 08:42:07 +00:00
|
|
|
}
|
|
|
|
|
2010-12-16 06:56:08 +00:00
|
|
|
_git_reflog ()
|
|
|
|
{
|
|
|
|
local subcommands="show delete expire"
|
|
|
|
local subcommand="$(__git_find_on_cmdline "$subcommands")"
|
|
|
|
|
|
|
|
if [ -z "$subcommand" ]; then
|
|
|
|
__gitcomp "$subcommands"
|
|
|
|
else
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2010-12-16 06:56:08 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2009-05-04 06:25:35 +00:00
|
|
|
__git_send_email_confirm_options="always never auto cc compose"
|
2009-06-18 12:31:32 +00:00
|
|
|
__git_send_email_suppresscc_options="author self cc bodycc sob cccmd body all"
|
2009-05-04 06:25:35 +00:00
|
|
|
|
2008-07-14 08:21:02 +00:00
|
|
|
_git_send_email ()
|
|
|
|
{
|
2015-11-19 22:52:12 +00:00
|
|
|
case "$prev" in
|
|
|
|
--to|--cc|--bcc|--from)
|
|
|
|
__gitcomp "
|
|
|
|
$(git --git-dir="$(__gitdir)" send-email --dump-aliases 2>/dev/null)
|
2015-12-12 00:18:18 +00:00
|
|
|
"
|
2015-11-19 22:52:12 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2008-07-14 08:21:02 +00:00
|
|
|
case "$cur" in
|
2009-05-04 06:25:35 +00:00
|
|
|
--confirm=*)
|
|
|
|
__gitcomp "
|
|
|
|
$__git_send_email_confirm_options
|
|
|
|
" "" "${cur##--confirm=}"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
--suppress-cc=*)
|
|
|
|
__gitcomp "
|
|
|
|
$__git_send_email_suppresscc_options
|
|
|
|
" "" "${cur##--suppress-cc=}"
|
|
|
|
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
--smtp-encryption=*)
|
|
|
|
__gitcomp "ssl tls" "" "${cur##--smtp-encryption=}"
|
|
|
|
return
|
|
|
|
;;
|
2012-10-16 00:21:50 +00:00
|
|
|
--thread=*)
|
|
|
|
__gitcomp "
|
|
|
|
deep shallow
|
|
|
|
" "" "${cur##--thread=}"
|
|
|
|
return
|
|
|
|
;;
|
2015-11-19 22:52:12 +00:00
|
|
|
--to=*|--cc=*|--bcc=*|--from=*)
|
|
|
|
__gitcomp "
|
|
|
|
$(git --git-dir="$(__gitdir)" send-email --dump-aliases 2>/dev/null)
|
|
|
|
" "" "${cur#--*=}"
|
|
|
|
return
|
|
|
|
;;
|
2008-07-14 08:21:02 +00:00
|
|
|
--*)
|
2009-03-23 10:26:49 +00:00
|
|
|
__gitcomp "--annotate --bcc --cc --cc-cmd --chain-reply-to
|
2009-05-04 06:25:35 +00:00
|
|
|
--compose --confirm= --dry-run --envelope-sender
|
|
|
|
--from --identity
|
2008-07-14 08:21:02 +00:00
|
|
|
--in-reply-to --no-chain-reply-to --no-signed-off-by-cc
|
|
|
|
--no-suppress-from --no-thread --quiet
|
|
|
|
--signed-off-by-cc --smtp-pass --smtp-server
|
2009-05-04 06:25:35 +00:00
|
|
|
--smtp-server-port --smtp-encryption= --smtp-user
|
|
|
|
--subject --suppress-cc= --suppress-from --thread --to
|
2012-10-16 00:21:50 +00:00
|
|
|
--validate --no-validate
|
|
|
|
$__git_format_patch_options"
|
2008-07-14 08:21:02 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2012-10-16 00:21:50 +00:00
|
|
|
__git_complete_revlist
|
2008-07-14 08:21:02 +00:00
|
|
|
}
|
|
|
|
|
bash: support user-supplied completion scripts for user's git commands
The bash completion script already provides support to complete
aliases, options and refs for aliases (if the alias can be traced back
to a supported git command by __git_aliased_command()), and the user's
custom git commands, but it does not support the options of the user's
custom git commands (of course; how could it know about the options of
a custom git command?). Users of such custom git commands could
extend git's bash completion script by writing functions to support
their commands, but they might have issues with it: they might not
have the rights to modify a system-wide git completion script, and
they will need to track and merge upstream changes in the future.
This patch addresses this by providing means for users to supply
custom completion scriplets for their custom git commands without
modifying the main git bash completion script.
Instead of having a huge hard-coded list of command-completion
function pairs (in _git()), the completion script will figure out
which completion function to call based on the command's name. That
is, when completing the options of 'git foo', the main completion
script will check whether the function '_git_foo' is declared, and if
declared, it will invoke that function to perform the completion. If
such a function is not declared, it will fall back to complete file
names. So, users will only need to provide this '_git_foo' completion
function in a separate file, source that file, and it will be used the
next time they press TAB after 'git foo '.
There are two git commands (stage and whatchanged), for which the
completion functions of other commands were used, therefore they
got their own completion function.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:58 +00:00
|
|
|
_git_stage ()
|
|
|
|
{
|
|
|
|
_git_add
|
|
|
|
}
|
|
|
|
|
2009-05-09 01:23:32 +00:00
|
|
|
__git_config_get_set_variables ()
|
|
|
|
{
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
local prevword word config_file= c=$cword
|
2009-05-09 01:23:32 +00:00
|
|
|
while [ $c -gt 1 ]; do
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
word="${words[c]}"
|
2009-05-09 01:23:32 +00:00
|
|
|
case "$word" in
|
2013-02-12 12:20:42 +00:00
|
|
|
--system|--global|--local|--file=*)
|
2009-05-09 01:23:32 +00:00
|
|
|
config_file="$word"
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-f|--file)
|
|
|
|
config_file="$word $prevword"
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
prevword=$word
|
|
|
|
c=$((--c))
|
|
|
|
done
|
|
|
|
|
2015-08-10 09:46:07 +00:00
|
|
|
git --git-dir="$(__gitdir)" config $config_file --name-only --list 2>/dev/null
|
2009-05-09 01:23:32 +00:00
|
|
|
}
|
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
_git_config ()
|
2006-11-27 09:44:47 +00:00
|
|
|
{
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
case "$prev" in
|
2013-04-29 12:49:40 +00:00
|
|
|
branch.*.remote|branch.*.pushremote)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
branch.*.merge)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
2013-04-29 12:49:39 +00:00
|
|
|
branch.*.rebase)
|
|
|
|
__gitcomp "false true"
|
|
|
|
return
|
|
|
|
;;
|
2013-04-29 12:49:41 +00:00
|
|
|
remote.pushdefault)
|
|
|
|
__gitcomp_nl "$(__git_remotes)"
|
|
|
|
return
|
|
|
|
;;
|
2006-11-27 09:44:47 +00:00
|
|
|
remote.*.fetch)
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
local remote="${prev#remote.}"
|
2006-11-27 09:44:47 +00:00
|
|
|
remote="${remote%.fetch}"
|
2011-10-08 14:54:42 +00:00
|
|
|
if [ -z "$cur" ]; then
|
2013-05-21 00:33:03 +00:00
|
|
|
__gitcomp_nl "refs/heads/" "" "" ""
|
2011-10-08 14:54:42 +00:00
|
|
|
return
|
|
|
|
fi
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs_remotes "$remote")"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
remote.*.push)
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
local remote="${prev#remote.}"
|
2006-11-27 09:44:47 +00:00
|
|
|
remote="${remote%.push}"
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(git --git-dir="$(__gitdir)" \
|
2006-11-27 09:44:47 +00:00
|
|
|
for-each-ref --format='%(refname):%(refname)' \
|
2007-02-04 07:38:37 +00:00
|
|
|
refs/heads)"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
pull.twohead|pull.octopus)
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_compute_merge_strategies
|
|
|
|
__gitcomp "$__git_merge_strategies"
|
2007-02-04 07:38:37 +00:00
|
|
|
return
|
|
|
|
;;
|
2009-04-25 11:46:14 +00:00
|
|
|
color.branch|color.diff|color.interactive|\
|
|
|
|
color.showbranch|color.status|color.ui)
|
2007-02-04 07:38:37 +00:00
|
|
|
__gitcomp "always never auto"
|
|
|
|
return
|
|
|
|
;;
|
2009-02-12 15:55:54 +00:00
|
|
|
color.pager)
|
|
|
|
__gitcomp "false true"
|
|
|
|
return
|
|
|
|
;;
|
2007-02-04 07:38:37 +00:00
|
|
|
color.*.*)
|
|
|
|
__gitcomp "
|
2008-12-15 17:45:49 +00:00
|
|
|
normal black red green yellow blue magenta cyan white
|
2007-02-04 07:38:37 +00:00
|
|
|
bold dim ul blink reverse
|
|
|
|
"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
2013-04-29 12:49:38 +00:00
|
|
|
diff.submodule)
|
|
|
|
__gitcomp "log short"
|
|
|
|
return
|
|
|
|
;;
|
2009-05-04 06:25:33 +00:00
|
|
|
help.format)
|
|
|
|
__gitcomp "man info web html"
|
|
|
|
return
|
|
|
|
;;
|
2009-05-04 06:25:34 +00:00
|
|
|
log.date)
|
|
|
|
__gitcomp "$__git_log_date_formats"
|
|
|
|
return
|
|
|
|
;;
|
2009-05-04 06:25:35 +00:00
|
|
|
sendemail.aliasesfiletype)
|
|
|
|
__gitcomp "mutt mailrc pine elm gnus"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
sendemail.confirm)
|
|
|
|
__gitcomp "$__git_send_email_confirm_options"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
sendemail.suppresscc)
|
|
|
|
__gitcomp "$__git_send_email_suppresscc_options"
|
|
|
|
return
|
|
|
|
;;
|
git-send-email: add --transfer-encoding option
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings. In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eol and friends on it.
Right now, the best option is to use "git am --keep-cr". However, when
a patch create new files, the patch application process will reject the
new file because it finds a "/dev/null\r" string instead of "/dev/null".
The problem is that SMTP transport is CRLF-unsafe. Sending a patch by
email is the same as passing it through "dos2unix | unix2dos". The newly
introduced CRLFs are normally transparent because git-am strips them. The
keepcr=true setting preserves them, but it is mostly working by chance
and it would be very problematic to have a "git am" workflow in a
repository with mixed LF and CRLF line endings.
The MIME solution to this is the quoted-printable transfer enconding.
This is not something that we want to enable by default, since it makes
received emails horrible to look at. However, it is a very good match
for projects that store CRLF line endings in the repository.
The only disadvantage of quoted-printable is that quoted-printable
patches fail to apply if the maintainer uses "git am --keep-cr". This
is because the decoded patch will have two carriage returns at the end
of the line. Therefore, add support for base64 transfer encoding too,
which makes received emails downright impossible to look at outside
a MUA, but really just works.
The patch covers all bases, including users that still live in the late
80s, by also providing a 7bit content transfer encoding that refuses
to send emails with non-ASCII character in them. And finally, "8bit"
will add a Content-Transfer-Encoding header but otherwise do nothing.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 14:00:27 +00:00
|
|
|
sendemail.transferencoding)
|
|
|
|
__gitcomp "7bit 8bit quoted-printable base64"
|
|
|
|
return
|
|
|
|
;;
|
2009-05-09 01:23:32 +00:00
|
|
|
--get|--get-all|--unset|--unset-all)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_config_get_set_variables)"
|
2009-05-09 01:23:32 +00:00
|
|
|
return
|
|
|
|
;;
|
2006-11-27 09:44:47 +00:00
|
|
|
*.*)
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
2007-02-04 07:38:37 +00:00
|
|
|
__gitcomp "
|
2013-02-12 12:20:42 +00:00
|
|
|
--system --global --local --file=
|
2007-05-24 06:07:45 +00:00
|
|
|
--list --replace-all
|
2006-11-27 09:44:47 +00:00
|
|
|
--get --get-all --get-regexp
|
2007-02-05 20:44:32 +00:00
|
|
|
--add --unset --unset-all
|
2007-05-24 06:07:45 +00:00
|
|
|
--remove-section --rename-section
|
2015-08-10 09:46:06 +00:00
|
|
|
--name-only
|
2007-02-04 07:38:37 +00:00
|
|
|
"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
branch.*.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur##*.}"
|
2013-04-29 12:49:40 +00:00
|
|
|
__gitcomp "remote pushremote merge mergeoptions rebase" "$pfx" "$cur_"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
branch.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur#*.}"
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
|
2014-01-05 10:18:04 +00:00
|
|
|
__gitcomp_nl_append $'autosetupmerge\nautosetuprebase\n' "$pfx" "$cur_"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
2009-05-04 06:25:32 +00:00
|
|
|
guitool.*.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur##*.}"
|
2009-05-04 06:25:32 +00:00
|
|
|
__gitcomp "
|
|
|
|
argprompt cmd confirm needsfile noconsole norescan
|
|
|
|
prompt revprompt revunmerged title
|
2011-04-28 16:01:51 +00:00
|
|
|
" "$pfx" "$cur_"
|
2009-05-04 06:25:32 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
difftool.*.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur##*.}"
|
|
|
|
__gitcomp "cmd path" "$pfx" "$cur_"
|
2009-05-04 06:25:32 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
man.*.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur##*.}"
|
|
|
|
__gitcomp "cmd path" "$pfx" "$cur_"
|
2009-05-04 06:25:32 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
mergetool.*.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur##*.}"
|
|
|
|
__gitcomp "cmd path trustExitCode" "$pfx" "$cur_"
|
2009-05-04 06:25:32 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
pager.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur#*.}"
|
2009-11-18 00:49:10 +00:00
|
|
|
__git_compute_all_commands
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$__git_all_commands" "$pfx" "$cur_"
|
2009-05-04 06:25:32 +00:00
|
|
|
return
|
|
|
|
;;
|
2006-11-27 09:44:47 +00:00
|
|
|
remote.*.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur##*.}"
|
2007-05-24 06:07:45 +00:00
|
|
|
__gitcomp "
|
2008-12-15 17:45:49 +00:00
|
|
|
url proxy fetch push mirror skipDefaultUpdate
|
2009-06-30 04:24:24 +00:00
|
|
|
receivepack uploadpack tagopt pushurl
|
2011-04-28 16:01:51 +00:00
|
|
|
" "$pfx" "$cur_"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
remote.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur#*.}"
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)" "$pfx" "$cur_" "."
|
2014-01-05 10:18:05 +00:00
|
|
|
__gitcomp_nl_append "pushdefault" "$pfx" "$cur_"
|
2006-11-27 09:44:47 +00:00
|
|
|
return
|
|
|
|
;;
|
2009-05-04 06:25:32 +00:00
|
|
|
url.*.*)
|
2011-04-28 16:01:51 +00:00
|
|
|
local pfx="${cur%.*}." cur_="${cur##*.}"
|
|
|
|
__gitcomp "insteadOf pushInsteadOf" "$pfx" "$cur_"
|
2009-05-04 06:25:32 +00:00
|
|
|
return
|
|
|
|
;;
|
2006-11-27 09:44:47 +00:00
|
|
|
esac
|
2007-02-04 07:38:37 +00:00
|
|
|
__gitcomp "
|
2010-12-20 15:18:25 +00:00
|
|
|
add.ignoreErrors
|
|
|
|
advice.commitBeforeMerge
|
|
|
|
advice.detachedHead
|
|
|
|
advice.implicitIdentity
|
|
|
|
advice.pushNonFastForward
|
|
|
|
advice.resolveConflict
|
|
|
|
advice.statusHints
|
2009-05-04 06:25:31 +00:00
|
|
|
alias.
|
2010-12-20 15:18:25 +00:00
|
|
|
am.keepcr
|
2009-08-04 11:16:49 +00:00
|
|
|
apply.ignorewhitespace
|
2006-11-27 09:44:47 +00:00
|
|
|
apply.whitespace
|
2008-12-15 17:45:49 +00:00
|
|
|
branch.autosetupmerge
|
|
|
|
branch.autosetuprebase
|
2010-12-20 15:18:25 +00:00
|
|
|
browser.
|
2007-04-24 00:18:16 +00:00
|
|
|
clean.requireForce
|
2007-02-04 07:38:37 +00:00
|
|
|
color.branch
|
|
|
|
color.branch.current
|
|
|
|
color.branch.local
|
|
|
|
color.branch.plain
|
2008-12-15 17:45:48 +00:00
|
|
|
color.branch.remote
|
2010-12-20 15:18:25 +00:00
|
|
|
color.decorate.HEAD
|
|
|
|
color.decorate.branch
|
|
|
|
color.decorate.remoteBranch
|
|
|
|
color.decorate.stash
|
|
|
|
color.decorate.tag
|
2006-12-13 09:13:28 +00:00
|
|
|
color.diff
|
2008-12-15 17:45:48 +00:00
|
|
|
color.diff.commit
|
2007-02-04 07:38:37 +00:00
|
|
|
color.diff.frag
|
2010-12-20 15:18:25 +00:00
|
|
|
color.diff.func
|
2008-12-15 17:45:48 +00:00
|
|
|
color.diff.meta
|
2007-02-04 07:38:37 +00:00
|
|
|
color.diff.new
|
2008-12-15 17:45:48 +00:00
|
|
|
color.diff.old
|
|
|
|
color.diff.plain
|
2007-02-04 07:38:37 +00:00
|
|
|
color.diff.whitespace
|
2009-05-04 06:25:31 +00:00
|
|
|
color.grep
|
2010-12-20 15:18:25 +00:00
|
|
|
color.grep.context
|
|
|
|
color.grep.filename
|
|
|
|
color.grep.function
|
|
|
|
color.grep.linenumber
|
2009-05-04 06:25:31 +00:00
|
|
|
color.grep.match
|
2010-12-20 15:18:25 +00:00
|
|
|
color.grep.selected
|
|
|
|
color.grep.separator
|
2008-12-15 17:45:49 +00:00
|
|
|
color.interactive
|
2010-12-20 15:18:25 +00:00
|
|
|
color.interactive.error
|
2008-12-15 17:45:49 +00:00
|
|
|
color.interactive.header
|
|
|
|
color.interactive.help
|
|
|
|
color.interactive.prompt
|
2006-12-13 09:13:28 +00:00
|
|
|
color.pager
|
2009-04-25 11:46:14 +00:00
|
|
|
color.showbranch
|
2006-12-13 09:13:28 +00:00
|
|
|
color.status
|
2007-02-04 07:38:37 +00:00
|
|
|
color.status.added
|
|
|
|
color.status.changed
|
2008-12-15 17:45:48 +00:00
|
|
|
color.status.header
|
2008-12-15 17:45:49 +00:00
|
|
|
color.status.nobranch
|
2015-03-10 16:11:09 +00:00
|
|
|
color.status.unmerged
|
2007-02-04 07:38:37 +00:00
|
|
|
color.status.untracked
|
2008-12-15 17:45:49 +00:00
|
|
|
color.status.updated
|
|
|
|
color.ui
|
2010-12-20 15:18:25 +00:00
|
|
|
commit.status
|
2008-12-15 17:45:49 +00:00
|
|
|
commit.template
|
2011-06-24 06:17:42 +00:00
|
|
|
core.abbrev
|
2010-12-20 15:18:25 +00:00
|
|
|
core.askpass
|
|
|
|
core.attributesfile
|
2008-12-15 17:45:49 +00:00
|
|
|
core.autocrlf
|
|
|
|
core.bare
|
2010-12-20 15:18:25 +00:00
|
|
|
core.bigFileThreshold
|
2008-12-15 17:45:48 +00:00
|
|
|
core.compression
|
2009-05-04 06:25:31 +00:00
|
|
|
core.createObject
|
2008-12-15 17:45:49 +00:00
|
|
|
core.deltaBaseCacheLimit
|
|
|
|
core.editor
|
2010-12-20 15:18:25 +00:00
|
|
|
core.eol
|
2008-12-15 17:45:49 +00:00
|
|
|
core.excludesfile
|
2008-12-15 17:45:48 +00:00
|
|
|
core.fileMode
|
2008-12-15 17:45:49 +00:00
|
|
|
core.fsyncobjectfiles
|
2008-12-15 17:45:48 +00:00
|
|
|
core.gitProxy
|
|
|
|
core.ignoreStat
|
2010-12-20 15:18:25 +00:00
|
|
|
core.ignorecase
|
2008-12-15 17:45:48 +00:00
|
|
|
core.logAllRefUpdates
|
|
|
|
core.loosecompression
|
2010-12-20 15:18:25 +00:00
|
|
|
core.notesRef
|
2008-12-15 17:45:48 +00:00
|
|
|
core.packedGitLimit
|
|
|
|
core.packedGitWindowSize
|
2008-12-15 17:45:49 +00:00
|
|
|
core.pager
|
2008-12-15 17:45:48 +00:00
|
|
|
core.preferSymlinkRefs
|
2008-12-15 17:45:49 +00:00
|
|
|
core.preloadindex
|
|
|
|
core.quotepath
|
2008-12-15 17:45:48 +00:00
|
|
|
core.repositoryFormatVersion
|
2008-12-15 17:45:49 +00:00
|
|
|
core.safecrlf
|
2008-12-15 17:45:48 +00:00
|
|
|
core.sharedRepository
|
2010-12-20 15:18:25 +00:00
|
|
|
core.sparseCheckout
|
2008-12-15 17:45:49 +00:00
|
|
|
core.symlinks
|
|
|
|
core.trustctime
|
2008-12-15 17:45:48 +00:00
|
|
|
core.warnAmbiguousRefs
|
2008-12-15 17:45:49 +00:00
|
|
|
core.whitespace
|
|
|
|
core.worktree
|
|
|
|
diff.autorefreshindex
|
|
|
|
diff.external
|
2010-12-20 15:18:25 +00:00
|
|
|
diff.ignoreSubmodules
|
2008-12-15 17:45:49 +00:00
|
|
|
diff.mnemonicprefix
|
2010-12-20 15:18:25 +00:00
|
|
|
diff.noprefix
|
2007-02-04 07:38:37 +00:00
|
|
|
diff.renameLimit
|
|
|
|
diff.renames
|
2013-04-29 12:49:37 +00:00
|
|
|
diff.statGraphWidth
|
2013-04-29 12:49:38 +00:00
|
|
|
diff.submodule
|
2009-05-04 06:25:31 +00:00
|
|
|
diff.suppressBlankEmpty
|
|
|
|
diff.tool
|
|
|
|
diff.wordRegex
|
2013-01-16 07:51:57 +00:00
|
|
|
diff.algorithm
|
2009-05-04 06:25:32 +00:00
|
|
|
difftool.
|
2009-05-04 06:25:31 +00:00
|
|
|
difftool.prompt
|
2010-12-20 15:18:25 +00:00
|
|
|
fetch.recurseSubmodules
|
2007-02-04 07:38:37 +00:00
|
|
|
fetch.unpackLimit
|
2009-05-04 06:25:31 +00:00
|
|
|
format.attach
|
|
|
|
format.cc
|
2014-01-06 17:18:51 +00:00
|
|
|
format.coverLetter
|
2007-02-04 07:38:37 +00:00
|
|
|
format.headers
|
2008-12-15 17:45:49 +00:00
|
|
|
format.numbered
|
|
|
|
format.pretty
|
2010-06-16 05:59:26 +00:00
|
|
|
format.signature
|
2009-05-04 06:25:31 +00:00
|
|
|
format.signoff
|
|
|
|
format.subjectprefix
|
2008-12-15 17:45:49 +00:00
|
|
|
format.suffix
|
2009-05-04 06:25:31 +00:00
|
|
|
format.thread
|
2010-12-20 15:18:25 +00:00
|
|
|
format.to
|
|
|
|
gc.
|
2008-12-15 17:45:49 +00:00
|
|
|
gc.aggressiveWindow
|
|
|
|
gc.auto
|
|
|
|
gc.autopacklimit
|
2007-05-24 06:07:45 +00:00
|
|
|
gc.packrefs
|
2008-12-15 17:45:49 +00:00
|
|
|
gc.pruneexpire
|
2007-02-04 07:38:37 +00:00
|
|
|
gc.reflogexpire
|
|
|
|
gc.reflogexpireunreachable
|
|
|
|
gc.rerereresolved
|
|
|
|
gc.rerereunresolved
|
2008-12-15 17:45:48 +00:00
|
|
|
gitcvs.allbinary
|
2009-05-04 06:25:31 +00:00
|
|
|
gitcvs.commitmsgannotation
|
2008-12-15 17:45:49 +00:00
|
|
|
gitcvs.dbTableNamePrefix
|
2008-12-15 17:45:48 +00:00
|
|
|
gitcvs.dbdriver
|
|
|
|
gitcvs.dbname
|
|
|
|
gitcvs.dbpass
|
|
|
|
gitcvs.dbuser
|
|
|
|
gitcvs.enabled
|
|
|
|
gitcvs.logfile
|
2008-12-15 17:45:49 +00:00
|
|
|
gitcvs.usecrlfattr
|
2009-05-04 06:25:32 +00:00
|
|
|
guitool.
|
2008-12-15 17:45:49 +00:00
|
|
|
gui.blamehistoryctx
|
|
|
|
gui.commitmsgwidth
|
|
|
|
gui.copyblamethreshold
|
|
|
|
gui.diffcontext
|
|
|
|
gui.encoding
|
|
|
|
gui.fastcopyblame
|
|
|
|
gui.matchtrackingbranch
|
|
|
|
gui.newbranchtemplate
|
|
|
|
gui.pruneduringfetch
|
|
|
|
gui.spellingdictionary
|
|
|
|
gui.trustmtime
|
|
|
|
help.autocorrect
|
|
|
|
help.browser
|
|
|
|
help.format
|
2007-02-04 07:38:37 +00:00
|
|
|
http.lowSpeedLimit
|
|
|
|
http.lowSpeedTime
|
2008-12-15 17:45:48 +00:00
|
|
|
http.maxRequests
|
2010-12-20 15:18:25 +00:00
|
|
|
http.minSessions
|
2006-11-27 09:44:47 +00:00
|
|
|
http.noEPSV
|
2010-12-20 15:18:25 +00:00
|
|
|
http.postBuffer
|
2008-12-15 17:45:49 +00:00
|
|
|
http.proxy
|
2015-05-08 13:22:15 +00:00
|
|
|
http.sslCipherList
|
2015-08-14 19:37:43 +00:00
|
|
|
http.sslVersion
|
2008-12-15 17:45:48 +00:00
|
|
|
http.sslCAInfo
|
|
|
|
http.sslCAPath
|
|
|
|
http.sslCert
|
2010-12-20 15:18:25 +00:00
|
|
|
http.sslCertPasswordProtected
|
2008-12-15 17:45:48 +00:00
|
|
|
http.sslKey
|
|
|
|
http.sslVerify
|
2010-12-20 15:18:25 +00:00
|
|
|
http.useragent
|
2007-02-04 07:38:37 +00:00
|
|
|
i18n.commitEncoding
|
|
|
|
i18n.logOutputEncoding
|
2010-12-20 15:18:25 +00:00
|
|
|
imap.authMethod
|
2009-05-04 06:25:31 +00:00
|
|
|
imap.folder
|
|
|
|
imap.host
|
|
|
|
imap.pass
|
|
|
|
imap.port
|
|
|
|
imap.preformattedHTML
|
|
|
|
imap.sslverify
|
|
|
|
imap.tunnel
|
|
|
|
imap.user
|
2010-12-20 15:18:25 +00:00
|
|
|
init.templatedir
|
2008-12-15 17:45:49 +00:00
|
|
|
instaweb.browser
|
|
|
|
instaweb.httpd
|
|
|
|
instaweb.local
|
|
|
|
instaweb.modulepath
|
|
|
|
instaweb.port
|
2009-05-04 06:25:31 +00:00
|
|
|
interactive.singlekey
|
2008-12-15 17:45:49 +00:00
|
|
|
log.date
|
2010-12-20 15:18:25 +00:00
|
|
|
log.decorate
|
2007-02-04 07:38:37 +00:00
|
|
|
log.showroot
|
2009-05-04 06:25:31 +00:00
|
|
|
mailmap.file
|
2009-05-04 06:25:32 +00:00
|
|
|
man.
|
2008-12-15 17:45:49 +00:00
|
|
|
man.viewer
|
2010-12-20 15:18:25 +00:00
|
|
|
merge.
|
2008-12-15 17:45:49 +00:00
|
|
|
merge.conflictstyle
|
|
|
|
merge.log
|
|
|
|
merge.renameLimit
|
2010-12-20 15:18:25 +00:00
|
|
|
merge.renormalize
|
2008-12-15 17:45:49 +00:00
|
|
|
merge.stat
|
2008-12-15 17:45:48 +00:00
|
|
|
merge.tool
|
2007-02-04 07:38:37 +00:00
|
|
|
merge.verbosity
|
2009-05-04 06:25:32 +00:00
|
|
|
mergetool.
|
2008-12-15 17:45:49 +00:00
|
|
|
mergetool.keepBackup
|
2010-12-20 15:18:25 +00:00
|
|
|
mergetool.keepTemporaries
|
2009-05-04 06:25:31 +00:00
|
|
|
mergetool.prompt
|
2010-12-20 15:18:25 +00:00
|
|
|
notes.displayRef
|
|
|
|
notes.rewrite.
|
|
|
|
notes.rewrite.amend
|
|
|
|
notes.rewrite.rebase
|
|
|
|
notes.rewriteMode
|
|
|
|
notes.rewriteRef
|
2007-08-23 05:39:22 +00:00
|
|
|
pack.compression
|
|
|
|
pack.deltaCacheLimit
|
2008-12-15 17:45:48 +00:00
|
|
|
pack.deltaCacheSize
|
|
|
|
pack.depth
|
2008-12-15 17:45:49 +00:00
|
|
|
pack.indexVersion
|
|
|
|
pack.packSizeLimit
|
|
|
|
pack.threads
|
2008-12-15 17:45:48 +00:00
|
|
|
pack.window
|
|
|
|
pack.windowMemory
|
2009-05-04 06:25:32 +00:00
|
|
|
pager.
|
2010-12-20 15:18:25 +00:00
|
|
|
pretty.
|
2007-02-04 07:38:37 +00:00
|
|
|
pull.octopus
|
|
|
|
pull.twohead
|
2009-05-04 06:25:31 +00:00
|
|
|
push.default
|
2015-02-16 06:16:19 +00:00
|
|
|
push.followTags
|
2010-12-20 15:18:25 +00:00
|
|
|
rebase.autosquash
|
2009-05-04 06:25:31 +00:00
|
|
|
rebase.stat
|
2010-12-20 15:18:25 +00:00
|
|
|
receive.autogc
|
2008-12-15 17:45:49 +00:00
|
|
|
receive.denyCurrentBranch
|
2010-12-20 15:18:25 +00:00
|
|
|
receive.denyDeleteCurrent
|
2008-12-15 17:45:49 +00:00
|
|
|
receive.denyDeletes
|
2008-12-15 17:45:48 +00:00
|
|
|
receive.denyNonFastForwards
|
2008-12-15 17:45:49 +00:00
|
|
|
receive.fsckObjects
|
2008-12-15 17:45:48 +00:00
|
|
|
receive.unpackLimit
|
2010-12-20 15:18:25 +00:00
|
|
|
receive.updateserverinfo
|
2013-04-29 12:49:41 +00:00
|
|
|
remote.pushdefault
|
2010-12-20 15:18:25 +00:00
|
|
|
remotes.
|
2008-12-15 17:45:49 +00:00
|
|
|
repack.usedeltabaseoffset
|
|
|
|
rerere.autoupdate
|
|
|
|
rerere.enabled
|
2010-12-20 15:18:25 +00:00
|
|
|
sendemail.
|
2009-05-04 06:25:31 +00:00
|
|
|
sendemail.aliasesfile
|
2010-12-20 15:18:25 +00:00
|
|
|
sendemail.aliasfiletype
|
2009-05-04 06:25:31 +00:00
|
|
|
sendemail.bcc
|
|
|
|
sendemail.cc
|
|
|
|
sendemail.cccmd
|
|
|
|
sendemail.chainreplyto
|
|
|
|
sendemail.confirm
|
|
|
|
sendemail.envelopesender
|
2010-12-20 15:18:25 +00:00
|
|
|
sendemail.from
|
|
|
|
sendemail.identity
|
2009-05-04 06:25:31 +00:00
|
|
|
sendemail.multiedit
|
|
|
|
sendemail.signedoffbycc
|
2010-12-20 15:18:25 +00:00
|
|
|
sendemail.smtpdomain
|
2009-05-04 06:25:31 +00:00
|
|
|
sendemail.smtpencryption
|
|
|
|
sendemail.smtppass
|
|
|
|
sendemail.smtpserver
|
2010-12-20 15:18:25 +00:00
|
|
|
sendemail.smtpserveroption
|
2009-05-04 06:25:31 +00:00
|
|
|
sendemail.smtpserverport
|
|
|
|
sendemail.smtpuser
|
|
|
|
sendemail.suppresscc
|
|
|
|
sendemail.suppressfrom
|
|
|
|
sendemail.thread
|
|
|
|
sendemail.to
|
|
|
|
sendemail.validate
|
2007-02-04 07:38:37 +00:00
|
|
|
showbranch.default
|
2008-12-15 17:45:49 +00:00
|
|
|
status.relativePaths
|
|
|
|
status.showUntrackedFiles
|
2010-12-20 15:18:25 +00:00
|
|
|
status.submodulesummary
|
|
|
|
submodule.
|
2007-02-04 07:38:37 +00:00
|
|
|
tar.umask
|
|
|
|
transfer.unpackLimit
|
2009-05-04 06:25:32 +00:00
|
|
|
url.
|
2007-02-04 07:38:37 +00:00
|
|
|
user.email
|
2008-12-15 17:45:48 +00:00
|
|
|
user.name
|
2007-02-04 07:38:37 +00:00
|
|
|
user.signingkey
|
2008-12-15 17:45:49 +00:00
|
|
|
web.browser
|
2006-11-27 09:44:47 +00:00
|
|
|
branch. remote.
|
2007-02-04 07:38:37 +00:00
|
|
|
"
|
2006-11-27 09:44:47 +00:00
|
|
|
}
|
|
|
|
|
2007-02-05 04:52:08 +00:00
|
|
|
_git_remote ()
|
|
|
|
{
|
2012-09-06 12:25:23 +00:00
|
|
|
local subcommands="add rename remove set-head set-branches set-url show prune update"
|
2009-09-15 10:21:43 +00:00
|
|
|
local subcommand="$(__git_find_on_cmdline "$subcommands")"
|
2008-03-10 15:02:23 +00:00
|
|
|
if [ -z "$subcommand" ]; then
|
2008-04-20 19:34:07 +00:00
|
|
|
__gitcomp "$subcommands"
|
2007-02-05 04:52:08 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2008-03-10 15:02:23 +00:00
|
|
|
case "$subcommand" in
|
2012-09-06 12:25:23 +00:00
|
|
|
rename|remove|set-url|show|prune)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_remotes)"
|
2007-02-05 04:52:08 +00:00
|
|
|
;;
|
2012-02-22 08:58:10 +00:00
|
|
|
set-head|set-branches)
|
|
|
|
__git_complete_remote_or_refspec
|
|
|
|
;;
|
2007-05-24 05:46:49 +00:00
|
|
|
update)
|
2015-05-10 12:50:17 +00:00
|
|
|
__gitcomp "$(__git_get_config_variables "remotes")"
|
2007-05-24 05:46:49 +00:00
|
|
|
;;
|
2007-02-05 04:52:08 +00:00
|
|
|
*)
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2009-10-09 20:49:06 +00:00
|
|
|
_git_replace ()
|
|
|
|
{
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2009-10-09 20:49:06 +00:00
|
|
|
}
|
|
|
|
|
2006-11-04 18:57:44 +00:00
|
|
|
_git_reset ()
|
|
|
|
{
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2007-02-04 07:38:43 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
2009-09-15 10:21:45 +00:00
|
|
|
__gitcomp "--merge --mixed --hard --soft --patch"
|
2007-02-04 07:38:43 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2006-11-04 18:57:44 +00:00
|
|
|
}
|
|
|
|
|
2008-08-05 05:50:34 +00:00
|
|
|
_git_revert ()
|
|
|
|
{
|
2015-05-25 09:59:35 +00:00
|
|
|
local dir="$(__gitdir)"
|
|
|
|
if [ -f "$dir"/REVERT_HEAD ]; then
|
|
|
|
__gitcomp "--continue --quit --abort"
|
|
|
|
return
|
|
|
|
fi
|
2008-08-05 05:50:34 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--edit --mainline --no-edit --no-commit --signoff"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2008-08-05 05:50:34 +00:00
|
|
|
}
|
|
|
|
|
2008-07-23 21:21:08 +00:00
|
|
|
_git_rm ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
|
|
|
|
__git_complete_index_file "--cached"
|
2008-07-23 21:21:08 +00:00
|
|
|
}
|
|
|
|
|
2007-05-24 05:25:34 +00:00
|
|
|
_git_shortlog ()
|
|
|
|
{
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2007-05-24 05:25:34 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
2009-02-16 16:34:56 +00:00
|
|
|
$__git_log_common_options
|
|
|
|
$__git_log_shortlog_options
|
2007-05-24 05:25:34 +00:00
|
|
|
--numbered --summary
|
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
__git_complete_revlist
|
|
|
|
}
|
|
|
|
|
2006-12-15 07:20:03 +00:00
|
|
|
_git_show ()
|
|
|
|
{
|
2008-10-31 00:04:46 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2006-12-15 07:20:03 +00:00
|
|
|
case "$cur" in
|
2011-10-08 01:09:34 +00:00
|
|
|
--pretty=*|--format=*)
|
2010-10-10 22:06:22 +00:00
|
|
|
__gitcomp "$__git_log_pretty_formats $(__git_pretty_aliases)
|
2011-10-08 01:09:34 +00:00
|
|
|
" "" "${cur#*=}"
|
2009-02-24 13:33:29 +00:00
|
|
|
return
|
|
|
|
;;
|
2013-01-16 07:51:58 +00:00
|
|
|
--diff-algorithm=*)
|
|
|
|
__gitcomp "$__git_diff_algorithms" "" "${cur##--diff-algorithm=}"
|
|
|
|
return
|
|
|
|
;;
|
2006-12-15 07:20:03 +00:00
|
|
|
--*)
|
2009-05-17 03:42:43 +00:00
|
|
|
__gitcomp "--pretty= --format= --abbrev-commit --oneline
|
2014-10-04 23:20:38 +00:00
|
|
|
--show-signature
|
2009-01-19 21:18:00 +00:00
|
|
|
$__git_diff_common_options
|
|
|
|
"
|
2006-12-15 07:20:03 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2013-06-02 14:03:42 +00:00
|
|
|
__git_complete_revlist_file
|
2006-12-15 07:20:03 +00:00
|
|
|
}
|
|
|
|
|
2008-07-23 21:36:15 +00:00
|
|
|
_git_show_branch ()
|
|
|
|
{
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--all --remotes --topo-order --current --more=
|
|
|
|
--list --independent --merge-base --no-name
|
2009-04-25 11:46:14 +00:00
|
|
|
--color --no-color
|
2009-05-17 03:42:43 +00:00
|
|
|
--sha1-name --sparse --topics --reflog
|
2008-07-23 21:36:15 +00:00
|
|
|
"
|
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
__git_complete_revlist
|
|
|
|
}
|
|
|
|
|
2007-08-03 09:04:37 +00:00
|
|
|
_git_stash ()
|
|
|
|
{
|
2009-09-15 10:21:44 +00:00
|
|
|
local save_opts='--keep-index --no-keep-index --quiet --patch'
|
2008-08-05 05:50:35 +00:00
|
|
|
local subcommands='save list show apply clear drop pop create branch'
|
2009-09-15 10:21:43 +00:00
|
|
|
local subcommand="$(__git_find_on_cmdline "$subcommands")"
|
2008-06-27 14:37:15 +00:00
|
|
|
if [ -z "$subcommand" ]; then
|
2009-09-15 10:21:44 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "$save_opts"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
if [ -z "$(__git_find_on_cmdline "$save_opts")" ]; then
|
|
|
|
__gitcomp "$subcommands"
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
esac
|
2008-06-27 14:37:15 +00:00
|
|
|
else
|
|
|
|
case "$subcommand,$cur" in
|
|
|
|
save,--*)
|
2009-09-15 10:21:44 +00:00
|
|
|
__gitcomp "$save_opts"
|
2008-06-27 14:37:15 +00:00
|
|
|
;;
|
2009-06-08 22:57:39 +00:00
|
|
|
apply,--*|pop,--*)
|
2009-09-15 10:21:44 +00:00
|
|
|
__gitcomp "--index --quiet"
|
2008-08-05 05:50:35 +00:00
|
|
|
;;
|
2009-06-08 22:57:39 +00:00
|
|
|
show,--*|drop,--*|branch,--*)
|
2008-08-05 05:50:35 +00:00
|
|
|
;;
|
|
|
|
show,*|apply,*|drop,*|pop,*|branch,*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(git --git-dir="$(__gitdir)" stash list \
|
2008-08-05 05:50:35 +00:00
|
|
|
| sed -n -e 's/:.*//p')"
|
|
|
|
;;
|
2008-06-27 14:37:15 +00:00
|
|
|
*)
|
|
|
|
;;
|
|
|
|
esac
|
2008-03-10 15:02:23 +00:00
|
|
|
fi
|
2007-08-03 09:04:37 +00:00
|
|
|
}
|
|
|
|
|
2007-08-23 05:50:49 +00:00
|
|
|
_git_submodule ()
|
|
|
|
{
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2013-03-04 21:20:24 +00:00
|
|
|
local subcommands="add status init deinit update summary foreach sync"
|
2009-09-15 10:21:43 +00:00
|
|
|
if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
|
2007-08-23 05:50:49 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "--quiet --cached"
|
|
|
|
;;
|
|
|
|
*)
|
2008-03-10 15:02:23 +00:00
|
|
|
__gitcomp "$subcommands"
|
2007-08-23 05:50:49 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2008-03-10 15:02:25 +00:00
|
|
|
_git_svn ()
|
|
|
|
{
|
|
|
|
local subcommands="
|
|
|
|
init fetch clone rebase dcommit log find-rev
|
|
|
|
set-tree commit-diff info create-ignore propget
|
2009-02-14 16:21:53 +00:00
|
|
|
proplist show-ignore show-externals branch tag blame
|
2009-12-30 00:58:48 +00:00
|
|
|
migrate mkdirs reset gc
|
2008-03-10 15:02:25 +00:00
|
|
|
"
|
2009-09-15 10:21:43 +00:00
|
|
|
local subcommand="$(__git_find_on_cmdline "$subcommands")"
|
2008-03-10 15:02:25 +00:00
|
|
|
if [ -z "$subcommand" ]; then
|
|
|
|
__gitcomp "$subcommands"
|
|
|
|
else
|
|
|
|
local remote_opts="--username= --config-dir= --no-auth-cache"
|
|
|
|
local fc_opts="
|
|
|
|
--follow-parent --authors-file= --repack=
|
|
|
|
--no-metadata --use-svm-props --use-svnsync-props
|
|
|
|
--log-window-size= --no-checkout --quiet
|
2009-02-14 16:21:53 +00:00
|
|
|
--repack-flags --use-log-author --localtime
|
2013-05-03 23:10:18 +00:00
|
|
|
--ignore-paths= --include-paths= $remote_opts
|
2008-03-10 15:02:25 +00:00
|
|
|
"
|
|
|
|
local init_opts="
|
|
|
|
--template= --shared= --trunk= --tags=
|
|
|
|
--branches= --stdlayout --minimize-url
|
|
|
|
--no-metadata --use-svm-props --use-svnsync-props
|
2009-02-14 16:21:53 +00:00
|
|
|
--rewrite-root= --prefix= --use-log-author
|
|
|
|
--add-author-from $remote_opts
|
2008-03-10 15:02:25 +00:00
|
|
|
"
|
|
|
|
local cmt_opts="
|
|
|
|
--edit --rmdir --find-copies-harder --copy-similarity=
|
|
|
|
"
|
|
|
|
|
|
|
|
case "$subcommand,$cur" in
|
|
|
|
fetch,--*)
|
|
|
|
__gitcomp "--revision= --fetch-all $fc_opts"
|
|
|
|
;;
|
|
|
|
clone,--*)
|
|
|
|
__gitcomp "--revision= $fc_opts $init_opts"
|
|
|
|
;;
|
|
|
|
init,--*)
|
|
|
|
__gitcomp "$init_opts"
|
|
|
|
;;
|
|
|
|
dcommit,--*)
|
|
|
|
__gitcomp "
|
|
|
|
--merge --strategy= --verbose --dry-run
|
2009-02-14 16:21:53 +00:00
|
|
|
--fetch-all --no-rebase --commit-url
|
2011-11-03 18:33:30 +00:00
|
|
|
--revision --interactive $cmt_opts $fc_opts
|
2008-03-10 15:02:25 +00:00
|
|
|
"
|
|
|
|
;;
|
|
|
|
set-tree,--*)
|
|
|
|
__gitcomp "--stdin $cmt_opts $fc_opts"
|
|
|
|
;;
|
|
|
|
create-ignore,--*|propget,--*|proplist,--*|show-ignore,--*|\
|
2009-12-30 00:58:48 +00:00
|
|
|
show-externals,--*|mkdirs,--*)
|
2008-03-10 15:02:25 +00:00
|
|
|
__gitcomp "--revision="
|
|
|
|
;;
|
|
|
|
log,--*)
|
|
|
|
__gitcomp "
|
|
|
|
--limit= --revision= --verbose --incremental
|
|
|
|
--oneline --show-commit --non-recursive
|
2009-02-14 16:21:53 +00:00
|
|
|
--authors-file= --color
|
2008-03-10 15:02:25 +00:00
|
|
|
"
|
|
|
|
;;
|
|
|
|
rebase,--*)
|
|
|
|
__gitcomp "
|
|
|
|
--merge --verbose --strategy= --local
|
2009-02-14 16:21:53 +00:00
|
|
|
--fetch-all --dry-run $fc_opts
|
2008-03-10 15:02:25 +00:00
|
|
|
"
|
|
|
|
;;
|
|
|
|
commit-diff,--*)
|
|
|
|
__gitcomp "--message= --file= --revision= $cmt_opts"
|
|
|
|
;;
|
|
|
|
info,--*)
|
|
|
|
__gitcomp "--url"
|
|
|
|
;;
|
2009-02-14 16:21:53 +00:00
|
|
|
branch,--*)
|
|
|
|
__gitcomp "--dry-run --message --tag"
|
|
|
|
;;
|
|
|
|
tag,--*)
|
|
|
|
__gitcomp "--dry-run --message"
|
|
|
|
;;
|
|
|
|
blame,--*)
|
|
|
|
__gitcomp "--git-format"
|
|
|
|
;;
|
|
|
|
migrate,--*)
|
|
|
|
__gitcomp "
|
|
|
|
--config-dir= --ignore-paths= --minimize
|
|
|
|
--no-auth-cache --username=
|
|
|
|
"
|
|
|
|
;;
|
2009-12-30 00:58:48 +00:00
|
|
|
reset,--*)
|
|
|
|
__gitcomp "--revision= --parent"
|
|
|
|
;;
|
2008-03-10 15:02:25 +00:00
|
|
|
*)
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2007-09-01 03:47:01 +00:00
|
|
|
_git_tag ()
|
|
|
|
{
|
|
|
|
local i c=1 f=0
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
while [ $c -lt $cword ]; do
|
|
|
|
i="${words[c]}"
|
2007-09-01 03:47:01 +00:00
|
|
|
case "$i" in
|
|
|
|
-d|-v)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_tags)"
|
2007-09-01 03:47:01 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
-f)
|
|
|
|
f=1
|
|
|
|
;;
|
|
|
|
esac
|
2012-02-22 08:58:11 +00:00
|
|
|
((c++))
|
2007-09-01 03:47:01 +00:00
|
|
|
done
|
|
|
|
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
case "$prev" in
|
2007-09-01 03:47:01 +00:00
|
|
|
-m|-F)
|
|
|
|
;;
|
2008-11-27 13:35:38 +00:00
|
|
|
-*|tag)
|
2007-09-01 03:47:01 +00:00
|
|
|
if [ $f = 1 ]; then
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_tags)"
|
2007-09-01 03:47:01 +00:00
|
|
|
fi
|
|
|
|
;;
|
|
|
|
*)
|
completion: optimize refs completion
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-15 12:57:23 +00:00
|
|
|
__gitcomp_nl "$(__git_refs)"
|
2007-09-01 03:47:01 +00:00
|
|
|
;;
|
|
|
|
esac
|
2014-12-04 18:07:35 +00:00
|
|
|
|
|
|
|
case "$cur" in
|
|
|
|
--*)
|
|
|
|
__gitcomp "
|
|
|
|
--list --delete --verify --annotate --message --file
|
|
|
|
--sign --cleanup --local-user --force --column --sort
|
|
|
|
--contains --points-at
|
|
|
|
"
|
|
|
|
;;
|
|
|
|
esac
|
2007-09-01 03:47:01 +00:00
|
|
|
}
|
|
|
|
|
bash: support user-supplied completion scripts for user's git commands
The bash completion script already provides support to complete
aliases, options and refs for aliases (if the alias can be traced back
to a supported git command by __git_aliased_command()), and the user's
custom git commands, but it does not support the options of the user's
custom git commands (of course; how could it know about the options of
a custom git command?). Users of such custom git commands could
extend git's bash completion script by writing functions to support
their commands, but they might have issues with it: they might not
have the rights to modify a system-wide git completion script, and
they will need to track and merge upstream changes in the future.
This patch addresses this by providing means for users to supply
custom completion scriplets for their custom git commands without
modifying the main git bash completion script.
Instead of having a huge hard-coded list of command-completion
function pairs (in _git()), the completion script will figure out
which completion function to call based on the command's name. That
is, when completing the options of 'git foo', the main completion
script will check whether the function '_git_foo' is declared, and if
declared, it will invoke that function to perform the completion. If
such a function is not declared, it will fall back to complete file
names. So, users will only need to provide this '_git_foo' completion
function in a separate file, source that file, and it will be used the
next time they press TAB after 'git foo '.
There are two git commands (stage and whatchanged), for which the
completion functions of other commands were used, therefore they
got their own completion function.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:58 +00:00
|
|
|
_git_whatchanged ()
|
|
|
|
{
|
|
|
|
_git_log
|
|
|
|
}
|
|
|
|
|
2012-06-13 08:08:50 +00:00
|
|
|
__git_main ()
|
2006-09-28 09:31:25 +00:00
|
|
|
{
|
2006-11-05 11:21:57 +00:00
|
|
|
local i c=1 command __git_dir
|
|
|
|
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
while [ $c -lt $cword ]; do
|
|
|
|
i="${words[c]}"
|
2006-11-05 11:21:57 +00:00
|
|
|
case "$i" in
|
|
|
|
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
|
2013-06-22 11:25:17 +00:00
|
|
|
--git-dir) ((c++)) ; __git_dir="${words[c]}" ;;
|
2006-11-05 11:21:57 +00:00
|
|
|
--bare) __git_dir="." ;;
|
2008-07-24 00:07:23 +00:00
|
|
|
--help) command="help"; break ;;
|
2013-06-22 11:25:17 +00:00
|
|
|
-c|--work-tree|--namespace) ((c++)) ;;
|
completion: fix completion after 'git --option <TAB>'
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-15 19:44:20 +00:00
|
|
|
-*) ;;
|
2006-11-05 11:21:57 +00:00
|
|
|
*) command="$i"; break ;;
|
|
|
|
esac
|
2012-02-22 08:58:11 +00:00
|
|
|
((c++))
|
2006-11-05 11:21:57 +00:00
|
|
|
done
|
|
|
|
|
2008-03-10 15:02:22 +00:00
|
|
|
if [ -z "$command" ]; then
|
bash: get --pretty=m<tab> completion to work with bash v4
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this also improves behavior when tab is pressed with the
cursor in the middle of a word.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then a
shim that just reads COMP_WORDS will be used instead (no change from
the current behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
2010-12-02 08:17:13 +00:00
|
|
|
case "$cur" in
|
2007-08-23 05:39:22 +00:00
|
|
|
--*) __gitcomp "
|
2008-03-06 16:52:37 +00:00
|
|
|
--paginate
|
2007-08-23 05:39:22 +00:00
|
|
|
--no-pager
|
|
|
|
--git-dir=
|
|
|
|
--bare
|
|
|
|
--version
|
|
|
|
--exec-path
|
2012-04-15 19:44:19 +00:00
|
|
|
--exec-path=
|
2009-04-05 02:15:16 +00:00
|
|
|
--html-path
|
2013-06-22 11:25:18 +00:00
|
|
|
--man-path
|
2012-04-15 19:44:18 +00:00
|
|
|
--info-path
|
2008-03-06 16:52:37 +00:00
|
|
|
--work-tree=
|
ref namespaces: infrastructure
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-07-05 17:54:44 +00:00
|
|
|
--namespace=
|
2012-04-15 19:44:18 +00:00
|
|
|
--no-replace-objects
|
2008-03-06 16:52:37 +00:00
|
|
|
--help
|
2007-08-23 05:39:22 +00:00
|
|
|
"
|
|
|
|
;;
|
2009-11-18 00:49:10 +00:00
|
|
|
*) __git_compute_porcelain_commands
|
|
|
|
__gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
|
2007-02-04 07:38:27 +00:00
|
|
|
esac
|
|
|
|
return
|
2006-11-05 11:21:57 +00:00
|
|
|
fi
|
2006-10-28 12:12:20 +00:00
|
|
|
|
bash: support user-supplied completion scripts for user's git commands
The bash completion script already provides support to complete
aliases, options and refs for aliases (if the alias can be traced back
to a supported git command by __git_aliased_command()), and the user's
custom git commands, but it does not support the options of the user's
custom git commands (of course; how could it know about the options of
a custom git command?). Users of such custom git commands could
extend git's bash completion script by writing functions to support
their commands, but they might have issues with it: they might not
have the rights to modify a system-wide git completion script, and
they will need to track and merge upstream changes in the future.
This patch addresses this by providing means for users to supply
custom completion scriplets for their custom git commands without
modifying the main git bash completion script.
Instead of having a huge hard-coded list of command-completion
function pairs (in _git()), the completion script will figure out
which completion function to call based on the command's name. That
is, when completing the options of 'git foo', the main completion
script will check whether the function '_git_foo' is declared, and if
declared, it will invoke that function to perform the completion. If
such a function is not declared, it will fall back to complete file
names. So, users will only need to provide this '_git_foo' completion
function in a separate file, source that file, and it will be used the
next time they press TAB after 'git foo '.
There are two git commands (stage and whatchanged), for which the
completion functions of other commands were used, therefore they
got their own completion function.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:58 +00:00
|
|
|
local completion_func="_git_${command//-/_}"
|
completion: make compatible with zsh
Modify git-completion.bash so that it also works with zsh when using
bashcompinit. In particular:
declare -F
Zsh doesn't have the same 'declare -F' as bash, but 'declare -f'
is the same, and it works just as well for our purposes.
${var:2}
Zsh does not implement ${var:2} to skip the first 2 characters, but
${var#??} works in both shells to replace the first 2 characters
with nothing. Thanks to Jonathan Nieder for the suggestion.
for (( n=1; "$n" ... ))
Zsh does not allow "$var" in arithmetic loops. Instead, pre-compute
the endpoint and use the variables without $'s or quotes.
shopt
Zsh uses 'setopt', which has a different syntax than 'shopt'. Since
'shopt' is used infrequently in git-completion, we provide
a bare-bones emulation.
emulate -L bash
KSH_TYPESET
Zsh offers bash emulation, which turns on a set of features to
closely resemble bash. In particular, this enables SH_WORDSPLIT,
which splits scalar variables on word boundaries in 'for' loops.
We also need to set KSH_TYPESET, to fix "local var=$(echo foo bar)"
issues.
The last set of options are turned on only in _git and _gitk. Some of
the sub-functions may not work correctly if called directly.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06 12:33:19 +00:00
|
|
|
declare -f $completion_func >/dev/null && $completion_func && return
|
bash: support user-supplied completion scripts for aliases
Shell command aliases can get rather complex, and the completion
script can not always determine correctly the git command invoked by
such an alias. For such cases users might want to provide custom
completion scripts the same way like for their custom commands made
possible by the previous patch.
The current completion script does not allow this, because if it
encounters an alias, then it will unconditionally perform completion
for the aliased git command (in case it can determine the aliased git
command, of course). With this patch the completion script will first
search for a completion function for the command given on the command
line, be it a git command, a custom git command of the user, or an
alias, and invoke that function to perform the completion. This has
no effect on git commands, because they can not be aliased anyway. If
it is an alias and there is a completion function for that alias (e.g.
_git_foo() for the alias 'foo'), then it will be invoked to perform
completion, allowing users to provide custom completion functions for
aliases. If such a completion function can not be found, only then
will the completion script check whether the command given on the
command line is an alias or not, and proceed as usual (i.e. find out
the aliased git command and provide completion for it).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:59 +00:00
|
|
|
|
2006-11-05 11:21:57 +00:00
|
|
|
local expansion=$(__git_aliased_command "$command")
|
bash: support user-supplied completion scripts for aliases
Shell command aliases can get rather complex, and the completion
script can not always determine correctly the git command invoked by
such an alias. For such cases users might want to provide custom
completion scripts the same way like for their custom commands made
possible by the previous patch.
The current completion script does not allow this, because if it
encounters an alias, then it will unconditionally perform completion
for the aliased git command (in case it can determine the aliased git
command, of course). With this patch the completion script will first
search for a completion function for the command given on the command
line, be it a git command, a custom git command of the user, or an
alias, and invoke that function to perform the completion. This has
no effect on git commands, because they can not be aliased anyway. If
it is an alias and there is a completion function for that alias (e.g.
_git_foo() for the alias 'foo'), then it will be invoked to perform
completion, allowing users to provide custom completion functions for
aliases. If such a completion function can not be found, only then
will the completion script check whether the command given on the
command line is an alias or not, and proceed as usual (i.e. find out
the aliased git command and provide completion for it).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:59 +00:00
|
|
|
if [ -n "$expansion" ]; then
|
2014-04-09 18:50:04 +00:00
|
|
|
words[1]=$expansion
|
bash: support user-supplied completion scripts for aliases
Shell command aliases can get rather complex, and the completion
script can not always determine correctly the git command invoked by
such an alias. For such cases users might want to provide custom
completion scripts the same way like for their custom commands made
possible by the previous patch.
The current completion script does not allow this, because if it
encounters an alias, then it will unconditionally perform completion
for the aliased git command (in case it can determine the aliased git
command, of course). With this patch the completion script will first
search for a completion function for the command given on the command
line, be it a git command, a custom git command of the user, or an
alias, and invoke that function to perform the completion. This has
no effect on git commands, because they can not be aliased anyway. If
it is an alias and there is a completion function for that alias (e.g.
_git_foo() for the alias 'foo'), then it will be invoked to perform
completion, allowing users to provide custom completion functions for
aliases. If such a completion function can not be found, only then
will the completion script check whether the command given on the
command line is an alias or not, and proceed as usual (i.e. find out
the aliased git command and provide completion for it).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:59 +00:00
|
|
|
completion_func="_git_${expansion//-/_}"
|
completion: make compatible with zsh
Modify git-completion.bash so that it also works with zsh when using
bashcompinit. In particular:
declare -F
Zsh doesn't have the same 'declare -F' as bash, but 'declare -f'
is the same, and it works just as well for our purposes.
${var:2}
Zsh does not implement ${var:2} to skip the first 2 characters, but
${var#??} works in both shells to replace the first 2 characters
with nothing. Thanks to Jonathan Nieder for the suggestion.
for (( n=1; "$n" ... ))
Zsh does not allow "$var" in arithmetic loops. Instead, pre-compute
the endpoint and use the variables without $'s or quotes.
shopt
Zsh uses 'setopt', which has a different syntax than 'shopt'. Since
'shopt' is used infrequently in git-completion, we provide
a bare-bones emulation.
emulate -L bash
KSH_TYPESET
Zsh offers bash emulation, which turns on a set of features to
closely resemble bash. In particular, this enables SH_WORDSPLIT,
which splits scalar variables on word boundaries in 'for' loops.
We also need to set KSH_TYPESET, to fix "local var=$(echo foo bar)"
issues.
The last set of options are turned on only in _git and _gitk. Some of
the sub-functions may not work correctly if called directly.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06 12:33:19 +00:00
|
|
|
declare -f $completion_func >/dev/null && $completion_func
|
bash: support user-supplied completion scripts for aliases
Shell command aliases can get rather complex, and the completion
script can not always determine correctly the git command invoked by
such an alias. For such cases users might want to provide custom
completion scripts the same way like for their custom commands made
possible by the previous patch.
The current completion script does not allow this, because if it
encounters an alias, then it will unconditionally perform completion
for the aliased git command (in case it can determine the aliased git
command, of course). With this patch the completion script will first
search for a completion function for the command given on the command
line, be it a git command, a custom git command of the user, or an
alias, and invoke that function to perform the completion. This has
no effect on git commands, because they can not be aliased anyway. If
it is an alias and there is a completion function for that alias (e.g.
_git_foo() for the alias 'foo'), then it will be invoked to perform
completion, allowing users to provide custom completion functions for
aliases. If such a completion function can not be found, only then
will the completion script check whether the command given on the
command line is an alias or not, and proceed as usual (i.e. find out
the aliased git command and provide completion for it).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 21:02:59 +00:00
|
|
|
fi
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2012-06-13 08:08:50 +00:00
|
|
|
__gitk_main ()
|
2006-09-28 09:31:25 +00:00
|
|
|
{
|
bash: offer only paths after '--'
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 16:56:14 +00:00
|
|
|
__git_has_doubledash && return
|
|
|
|
|
2009-02-11 18:03:23 +00:00
|
|
|
local g="$(__gitdir)"
|
2008-04-27 15:35:10 +00:00
|
|
|
local merge=""
|
2009-03-30 11:27:37 +00:00
|
|
|
if [ -f "$g/MERGE_HEAD" ]; then
|
2008-04-27 15:35:10 +00:00
|
|
|
merge="--merge"
|
|
|
|
fi
|
2007-02-04 07:38:43 +00:00
|
|
|
case "$cur" in
|
|
|
|
--*)
|
2009-02-16 16:34:56 +00:00
|
|
|
__gitcomp "
|
|
|
|
$__git_log_common_options
|
|
|
|
$__git_log_gitk_options
|
|
|
|
$merge
|
|
|
|
"
|
2007-02-04 07:38:43 +00:00
|
|
|
return
|
|
|
|
;;
|
|
|
|
esac
|
2007-02-04 07:38:47 +00:00
|
|
|
__git_complete_revlist
|
2006-09-28 09:31:25 +00:00
|
|
|
}
|
|
|
|
|
2012-11-18 11:08:09 +00:00
|
|
|
if [[ -n ${ZSH_VERSION-} ]]; then
|
|
|
|
echo "WARNING: this script is deprecated, please see git-completion.zsh" 1>&2
|
2012-05-14 15:35:18 +00:00
|
|
|
|
2012-11-29 08:20:57 +00:00
|
|
|
autoload -U +X compinit && compinit
|
|
|
|
|
2012-11-18 11:08:09 +00:00
|
|
|
__gitcomp ()
|
|
|
|
{
|
|
|
|
emulate -L zsh
|
2012-05-14 15:35:18 +00:00
|
|
|
|
2012-11-18 11:08:09 +00:00
|
|
|
local cur_="${3-$cur}"
|
|
|
|
|
|
|
|
case "$cur_" in
|
|
|
|
--*=)
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
local c IFS=$' \t\n'
|
|
|
|
local -a array
|
|
|
|
for c in ${=1}; do
|
|
|
|
c="$c${4-}"
|
|
|
|
case $c in
|
|
|
|
--*=*|*.) ;;
|
|
|
|
*) c="$c " ;;
|
|
|
|
esac
|
2013-08-21 20:49:31 +00:00
|
|
|
array[${#array[@]}+1]="$c"
|
2012-11-18 11:08:09 +00:00
|
|
|
done
|
|
|
|
compset -P '*[=:]'
|
|
|
|
compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
|
|
|
__gitcomp_nl ()
|
|
|
|
{
|
|
|
|
emulate -L zsh
|
|
|
|
|
|
|
|
local IFS=$'\n'
|
|
|
|
compset -P '*[=:]'
|
|
|
|
compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
|
|
|
|
}
|
|
|
|
|
git-completion.bash: add support for path completion
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>
2013-01-11 18:48:43 +00:00
|
|
|
__gitcomp_file ()
|
|
|
|
{
|
|
|
|
emulate -L zsh
|
|
|
|
|
|
|
|
local IFS=$'\n'
|
|
|
|
compset -P '*[=:]'
|
|
|
|
compadd -Q -p "${2-}" -f -- ${=1} && _ret=0
|
|
|
|
}
|
|
|
|
|
2012-11-18 11:08:09 +00:00
|
|
|
_git ()
|
|
|
|
{
|
2013-05-08 07:37:00 +00:00
|
|
|
local _ret=1 cur cword prev
|
|
|
|
cur=${words[CURRENT]}
|
|
|
|
prev=${words[CURRENT-1]}
|
|
|
|
let cword=CURRENT-1
|
|
|
|
emulate ksh -c __${service}_main
|
2013-05-08 07:37:01 +00:00
|
|
|
let _ret && _default && _ret=0
|
2012-11-18 11:08:09 +00:00
|
|
|
return _ret
|
|
|
|
}
|
|
|
|
|
|
|
|
compdef _git git gitk
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
__git_func_wrap ()
|
|
|
|
{
|
2012-05-14 15:35:18 +00:00
|
|
|
local cur words cword prev
|
|
|
|
_get_comp_words_by_ref -n =: cur words cword prev
|
|
|
|
$1
|
|
|
|
}
|
|
|
|
|
|
|
|
# Setup completion for certain functions defined above by setting common
|
|
|
|
# variables and workarounds.
|
|
|
|
# This is NOT a public function; use at your own risk.
|
|
|
|
__git_complete ()
|
|
|
|
{
|
|
|
|
local wrapper="__git_wrap${2}"
|
|
|
|
eval "$wrapper () { __git_func_wrap $2 ; }"
|
|
|
|
complete -o bashdefault -o default -o nospace -F $wrapper $1 2>/dev/null \
|
|
|
|
|| complete -o default -o nospace -F $wrapper $1
|
|
|
|
}
|
|
|
|
|
2012-05-19 02:41:35 +00:00
|
|
|
# wrapper for backwards compatibility
|
|
|
|
_git ()
|
|
|
|
{
|
2012-06-13 08:08:50 +00:00
|
|
|
__git_wrap__git_main
|
2012-05-19 02:41:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
# wrapper for backwards compatibility
|
|
|
|
_gitk ()
|
|
|
|
{
|
2012-06-13 08:08:50 +00:00
|
|
|
__git_wrap__gitk_main
|
2012-05-19 02:41:35 +00:00
|
|
|
}
|
|
|
|
|
2012-06-13 08:08:50 +00:00
|
|
|
__git_complete git __git_main
|
|
|
|
__git_complete gitk __gitk_main
|
2006-09-28 09:31:25 +00:00
|
|
|
|
|
|
|
# The following are necessary only for Cygwin, and only are needed
|
|
|
|
# when the user has tab-completed the executable name and consequently
|
|
|
|
# included the '.exe' suffix.
|
|
|
|
#
|
2006-11-05 11:20:25 +00:00
|
|
|
if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
|
2012-06-13 08:08:50 +00:00
|
|
|
__git_complete git.exe __git_main
|
2006-11-05 11:20:25 +00:00
|
|
|
fi
|