git-commit-vandalism/t/t9902-completion.sh

2633 lines
61 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2012-2020 Felipe Contreras
#
test_description='test bash completion'
. ./lib-bash.sh
complete ()
{
# do nothing
return 0
}
# Be careful when updating these lists:
#
# (1) The build tree may have build artifact from different branch, or
# the user's $PATH may have a random executable that may begin
# with "git-check" that are not part of the subcommands this build
# will ship, e.g. "check-ignore". The tests for completion for
# subcommand names tests how "check" is expanded; we limit the
# possible candidates to "checkout" and "check-attr" to make sure
# "check-attr", which is known by the filter function as a
# subcommand to be thrown out, while excluding other random files
# that happen to begin with "check" to avoid letting them get in
# the way.
#
# (2) A test makes sure that common subcommands are included in the
# completion for "git <TAB>", and a plumbing is excluded. "add",
# "rebase" and "ls-files" are listed for this.
GIT_TESTING_ALL_COMMAND_LIST='add checkout check-attr rebase ls-files'
GIT_TESTING_PORCELAIN_COMMAND_LIST='add checkout rebase'
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash"
# We don't need this function to actually join words or do anything special.
# Also, it's cleaner to avoid touching bash's internal completion variables.
# So let's override it with a minimal version for testing purposes.
_get_comp_words_by_ref ()
{
while [ $# -gt 0 ]; do
case "$1" in
cur)
cur=${_words[_cword]}
;;
prev)
prev=${_words[_cword-1]}
;;
words)
words=("${_words[@]}")
;;
cword)
cword=$_cword
;;
esac
shift
done
}
print_comp ()
{
local IFS=$'\n'
echo "${COMPREPLY[*]}" > out
}
run_completion ()
{
local -a COMPREPLY _words
local _cword
_words=( $1 )
test "${1: -1}" = ' ' && _words[${#_words[@]}+1]=''
(( _cword = ${#_words[@]} - 1 ))
__git_wrap__git_main && print_comp
}
# Test high-level completion
# Arguments are:
# 1: typed text so far (cur)
# 2: expected completion
test_completion ()
{
if test $# -gt 1
then
printf '%s\n' "$2" >expected
else
t9902-completion: ignore COMPREPLY element order in some tests The order or possible completion words in the COMPREPLY array doesn't actually matter, as long as all the right words are in there, because Bash will sort them anyway. Yet, our tests looking at the elements of COMPREPLY always expect them to be in a specific order. Now, this hasn't been an issue before, but the next patch is about to optimize a bit more our git-aware path completion, and as a harmless side effect the order of elements in COMPREPLY will change. Worse, the order will be downright undefined, because after the next patch path components will come directly from iterating through an associative array in 'awk', and the order of iteration over the elements in those arrays is undefined, and indeed different 'awk' implementations produce different order. Consequently, we can't get away with simply adjusting the expected results in the affected tests. Modify the 'test_completion' helper function to sort both the expected and the actual results, i.e. the elements in COMPREPLY, before comparing them, so the tests using this helper function will work regardless of the order of elements. Note that this change still leaves a bunch of tests depending on the order of elements in COMPREPLY, tests that focus on a specific helper function and therefore don't use the 'test_completion' helper. I would rather deal with those later, when (if ever) the need actually arises, than create unnecessary code churn now. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17 00:41:12 +02:00
sed -e 's/Z$//' |sort >expected
fi &&
run_completion "$1" &&
t9902-completion: ignore COMPREPLY element order in some tests The order or possible completion words in the COMPREPLY array doesn't actually matter, as long as all the right words are in there, because Bash will sort them anyway. Yet, our tests looking at the elements of COMPREPLY always expect them to be in a specific order. Now, this hasn't been an issue before, but the next patch is about to optimize a bit more our git-aware path completion, and as a harmless side effect the order of elements in COMPREPLY will change. Worse, the order will be downright undefined, because after the next patch path components will come directly from iterating through an associative array in 'awk', and the order of iteration over the elements in those arrays is undefined, and indeed different 'awk' implementations produce different order. Consequently, we can't get away with simply adjusting the expected results in the affected tests. Modify the 'test_completion' helper function to sort both the expected and the actual results, i.e. the elements in COMPREPLY, before comparing them, so the tests using this helper function will work regardless of the order of elements. Note that this change still leaves a bunch of tests depending on the order of elements in COMPREPLY, tests that focus on a specific helper function and therefore don't use the 'test_completion' helper. I would rather deal with those later, when (if ever) the need actually arises, than create unnecessary code churn now. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17 00:41:12 +02:00
sort out >out_sorted &&
test_cmp expected out_sorted
}
# Test __gitcomp.
# The first argument is the typed text so far (cur); the rest are
# passed to __gitcomp. Expected output comes is read from the
# standard input, like test_completion().
test_gitcomp ()
{
local -a COMPREPLY &&
sed -e 's/Z$//' >expected &&
local cur="$1" &&
shift &&
__gitcomp "$@" &&
print_comp &&
test_cmp expected out
}
# Test __gitcomp_nl
# Arguments are:
# 1: current word (cur)
# -: the rest are passed to __gitcomp_nl
test_gitcomp_nl ()
{
local -a COMPREPLY &&
sed -e 's/Z$//' >expected &&
local cur="$1" &&
shift &&
__gitcomp_nl "$@" &&
print_comp &&
test_cmp expected out
}
invalid_variable_name='${foo.bar}'
actual="$TRASH_DIRECTORY/actual"
if test_have_prereq MINGW
then
ROOT="$(pwd -W)"
else
ROOT="$(pwd)"
fi
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success 'setup for __git_find_repo_path/__gitdir tests' '
mkdir -p subdir/subsubdir &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
mkdir -p non-repo &&
git init -b main otherrepo
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - from command line (through $__git_dir)' '
echo "$ROOT/otherrepo/.git" >expected &&
(
__git_dir="$ROOT/otherrepo/.git" &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - .git directory in cwd' '
echo ".git" >expected &&
(
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - .git directory in parent' '
echo "$ROOT/.git" >expected &&
(
cd subdir/subsubdir &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - cwd is a .git directory' '
echo "." >expected &&
(
cd .git &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - parent is a .git directory' '
echo "$ROOT/.git" >expected &&
(
cd .git/objects &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - $GIT_DIR set while .git directory in cwd' '
echo "$ROOT/otherrepo/.git" >expected &&
(
GIT_DIR="$ROOT/otherrepo/.git" &&
export GIT_DIR &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - $GIT_DIR set while .git directory in parent' '
echo "$ROOT/otherrepo/.git" >expected &&
(
GIT_DIR="$ROOT/otherrepo/.git" &&
export GIT_DIR &&
cd subdir &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - from command line while "git -C"' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
echo "$ROOT/.git" >expected &&
(
__git_dir="$ROOT/.git" &&
__git_C_args=(-C otherrepo) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - relative dir from command line and "git -C"' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
echo "$ROOT/otherrepo/.git" >expected &&
(
cd subdir &&
__git_dir="otherrepo/.git" &&
__git_C_args=(-C ..) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - $GIT_DIR set while "git -C"' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
echo "$ROOT/.git" >expected &&
(
GIT_DIR="$ROOT/.git" &&
export GIT_DIR &&
__git_C_args=(-C otherrepo) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - relative dir in $GIT_DIR and "git -C"' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
echo "$ROOT/otherrepo/.git" >expected &&
(
cd subdir &&
GIT_DIR="otherrepo/.git" &&
export GIT_DIR &&
__git_C_args=(-C ..) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - "git -C" while .git directory in cwd' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
echo "$ROOT/otherrepo/.git" >expected &&
(
__git_C_args=(-C otherrepo) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - "git -C" while cwd is a .git directory' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
echo "$ROOT/otherrepo/.git" >expected &&
(
cd .git &&
__git_C_args=(-C .. -C otherrepo) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - "git -C" while .git directory in parent' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
echo "$ROOT/otherrepo/.git" >expected &&
(
cd subdir &&
__git_C_args=(-C .. -C otherrepo) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - non-existing path in "git -C"' '
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
(
__git_C_args=(-C non-existing) &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_must_fail __git_find_repo_path &&
printf "$__git_repo_path" >"$actual"
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
) &&
test_must_be_empty "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - non-existing path in $__git_dir' '
(
__git_dir="non-existing" &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_must_fail __git_find_repo_path &&
printf "$__git_repo_path" >"$actual"
) &&
test_must_be_empty "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - non-existing $GIT_DIR' '
(
GIT_DIR="$ROOT/non-existing" &&
export GIT_DIR &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_must_fail __git_find_repo_path &&
printf "$__git_repo_path" >"$actual"
) &&
test_must_be_empty "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - gitfile in cwd' '
echo "$ROOT/otherrepo/.git" >expected &&
echo "gitdir: $ROOT/otherrepo/.git" >subdir/.git &&
test_when_finished "rm -f subdir/.git" &&
(
cd subdir &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__git_find_repo_path - gitfile in parent' '
echo "$ROOT/otherrepo/.git" >expected &&
echo "gitdir: $ROOT/otherrepo/.git" >subdir/.git &&
test_when_finished "rm -f subdir/.git" &&
(
cd subdir/subsubdir &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success SYMLINKS '__git_find_repo_path - resulting path avoids symlinks' '
echo "$ROOT/otherrepo/.git" >expected &&
mkdir otherrepo/dir &&
test_when_finished "rm -rf otherrepo/dir" &&
ln -s otherrepo/dir link &&
test_when_finished "rm -f link" &&
(
cd link &&
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
__git_find_repo_path &&
echo "$__git_repo_path" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_find_repo_path - not a git repository' '
(
cd non-repo &&
GIT_CEILING_DIRECTORIES="$ROOT" &&
export GIT_CEILING_DIRECTORIES &&
test_must_fail __git_find_repo_path &&
printf "$__git_repo_path" >"$actual"
) &&
test_must_be_empty "$actual"
'
test_expect_success '__gitdir - finds repo' '
echo "$ROOT/.git" >expected &&
(
cd subdir/subsubdir &&
__gitdir >"$actual"
) &&
test_cmp expected "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__gitdir - returns error when cannot find repo' '
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
(
__git_dir="non-existing" &&
test_must_fail __gitdir >"$actual"
) &&
test_must_be_empty "$actual"
'
completion: cache the path to the repository After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:29 +01:00
test_expect_success '__gitdir - repo as argument' '
echo "otherrepo/.git" >expected &&
(
__gitdir "otherrepo" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__gitdir - remote as argument' '
echo "remote" >expected &&
(
__gitdir "remote" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: improve handling quoted paths on the command line Our git-aware path completion doesn't work when it has to complete a word already containing quoted and/or backslash-escaped characters on the command line. The root cause of the issue is that completion functions see all words on the command line verbatim, i.e. including all backslash, single and double quote characters that the shell would eventually remove when executing the finished command. These quoting/escaping characters cause different issues depending on which path component of the word to be completed contains them: - The quoting/escaping is in the prefix path component(s). Let's suppose we have a directory called 'New Dir', containing two untracked files 'file.c' and 'file.o', and we have a gitignore rule ignoring object files. In this case all of these: git add New\ Dir/<TAB> git add "New Dir/<TAB> git add 'New Dir/<TAB> should uniquely complete 'file.c' right away, but Bash offers both 'file.c' and 'file.o' instead. The reason for this behavior is that our completion script uses the prefix directory name like 'git -C "New\ Dir/" ls-files ...", i.e. with the backslash inside double quotes. Git then tries to enter a directory called 'New\ Dir', which (most likely) fails because such a directory doesn't exists. As a result our completion script doesn't list any files, leaves the COMPREPLY array empty, which in turn causes Bash to fall back to its simple filename completion and lists all files in that directory, i.e. both 'file.c' and 'file.o'. - The quoting/escaping is in the path component to be completed. Let's suppose we have two untracked files 'New File.c' and 'New File.o', and we have a gitignore rule ignoring object files. In this case all of these: git add New\ Fi<TAB> git add "New Fi<TAB> git add 'New Fi<TAB> should uniquely complete 'New File.c' right away, but Bash offers both 'New File.c' and 'New File.o' instead. The reason for this behavior is that our completion script uses this 'New\ Fi' or '"New Fi' etc. word to filter matching paths, and of course none of the potential filenames will match because of the included backslash or double quote. The end result is the same as above: the completion script doesn't list any files, Bash falls back to its filename completion, which then lists the matching object file as well. Add the new helper function __git_dequote() [1], which removes (most of[2]) the quoting and escaping from the word it gets as argument. To minimize the overhead of calling this function, store its result in the variable $dequoted_word, supposed to be declared local in the caller; simply printing the result would require a command substitution imposing the overhead of fork()ing a subshell. Use this function in __git_complete_index_file() to dequote the current word, i.e. the path, to be completed, to avoid the above described quoting-related issues, thereby fixing two of the failing quoted path completion tests. [1] The bash-completion project already has a dequote() function, which I hoped I could borrow to deal with this, but unfortunately it doesn't work quite well for this purpose (perhaps that's why even the bash-completion project only rarely uses it). The main issue is that their dequote() is implemented as: eval printf %s "$1" 2> /dev/null where $1 would contain the word to be completed. While it's a short and sweet one-liner, the use of 'eval' requires that $1 is a syntactically valid string, which is not the case when quoting the path like 'git add "New Dir/<TAB>'. This causes 'eval' to fail, because it can't find the matching closing double quote, and the function returns nothing. The result is totally broken behavior, as if the current word were empty, and the completion script would then list all files from the current directory. This is why one of the quoted path completion tests specifically checks the completion of a path with an opening but without a corresponding closing double quote character. Furthermore, the 'eval' performs all kinds of expansions, which may or may not be desired; I think it's the latter. Finally, using this function would require a command substitution. [2] Bash understands the $'string' quoting as well, which "expands to 'string', with backslash-escaped characters replaced as specified by the ANSI C standard" (quoted from Bash manpage). Since shell metacharacters, field separators, globbing, etc. can all be easily entered using standard shell escaping or quoting, this type of quoting comes in handly when dealing with control characters that are otherwise difficult both to "type" and to see on the command line. Because of this difficulty I would assume that people do avoid pathnames with such control characters anyway, so I didn't bother implementing it. This function is already way too long as it is. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17 00:41:09 +02:00
test_expect_success '__git_dequote - plain unquoted word' '
__git_dequote unquoted-word &&
verbose test unquoted-word = "$dequoted_word"
'
# input: b\a\c\k\'\\\"s\l\a\s\h\es
# expected: back'\"slashes
test_expect_success '__git_dequote - backslash escaped' '
__git_dequote "b\a\c\k\\'\''\\\\\\\"s\l\a\s\h\es" &&
verbose test "back'\''\\\"slashes" = "$dequoted_word"
'
# input: sin'gle\' '"quo'ted
# expected: single\ "quoted
test_expect_success '__git_dequote - single quoted' '
__git_dequote "'"sin'gle\\\\' '\\\"quo'ted"'" &&
verbose test '\''single\ "quoted'\'' = "$dequoted_word"
'
# input: dou"ble\\" "\"\quot"ed
# expected: double\ "\quoted
test_expect_success '__git_dequote - double quoted' '
__git_dequote '\''dou"ble\\" "\"\quot"ed'\'' &&
verbose test '\''double\ "\quoted'\'' = "$dequoted_word"
'
# input: 'open single quote
test_expect_success '__git_dequote - open single quote' '
__git_dequote "'\''open single quote" &&
verbose test "open single quote" = "$dequoted_word"
'
# input: "open double quote
test_expect_success '__git_dequote - open double quote' '
__git_dequote "\"open double quote" &&
verbose test "open double quote" = "$dequoted_word"
'
completion: fill COMPREPLY directly when completing refs __gitcomp_nl() iterates over all the possible completion words it gets as argument - filtering matching words, - appending a trailing space to each matching word (in all but two cases), - prepending a prefix to each matching word (when completing words after e.g. '--option=<TAB>' or 'master..<TAB>'), and - adding each matching word to the COMPREPLY array. This takes a while when a lot of refs are passed to __gitcomp_nl(). The previous changes in this series ensure that __git_refs() lists only refs matching the current word to be completed, making a second filtering in __gitcomp_nl() redundant. Adding the necessary prefix and suffix could be done in __git_refs() as well: - When refs come from 'git for-each-ref', then that prefix and suffix could be added much more efficiently using a 'git for-each-ref' format containing said prefix and suffix. Care should be taken, though, because that prefix might contain 'for-each-ref' format specifiers as part of the left hand side of a '..' range or '...' symmetric difference notation or fetch/push/etc. refspec, e.g. 'git log "evil-%(refname)..br<TAB>'. Doubling every '%' in the prefix will prevent 'git for-each-ref' from interpolating any of those contained specifiers. - When refs come from 'git ls-remote', then that prefix and suffix can be added in the shell loop that has to process 'git ls-remote's output anyway. - Finally, the prefix and suffix can be added to that handful of potentially matching symbolic and pseudo refs right away in the shell loop listing them. And then all what is still left to do is to assign a bunch of newline-separated words to a shell array, which can be done without a shell loop iterating over each word, basically making all of __gitcomp_nl() unnecessary for refs completion. Add the helper function __gitcomp_direct() to fill the COMPREPLY array with prefiltered and preprocessed words without any additional processing, without a shell loop, with just one single compound assignment. Modify __git_refs() to accept prefix and suffix parameters and add them to each and every listed ref as described above. Modify __git_complete_refs() to pass the prefix and suffix parameters to __git_refs() and to feed __git_refs()'s output to __gitcomp_direct() instead of __gitcomp_nl(). This speeds up refs completion when there are a lot of refs matching the current word to be completed. Listing all branches for completion in a repo with 100k local branches, all packed, best of five: On Linux, near the beginning of this series, for reference: $ time __git_complete_refs real 0m2.028s user 0m1.692s sys 0m0.344s Before this patch: real 0m1.135s user 0m1.112s sys 0m0.024s After: real 0m0.367s user 0m0.352s sys 0m0.020s On Windows, near the beginning: real 0m13.078s user 0m1.609s sys 0m0.060s Before this patch: real 0m2.093s user 0m1.641s sys 0m0.060s After: real 0m0.683s user 0m0.203s sys 0m0.076s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:22 +01:00
test_expect_success '__gitcomp_direct - puts everything into COMPREPLY as-is' '
sed -e "s/Z$//g" >expected <<-EOF &&
with-trailing-space Z
without-trailing-spaceZ
--option Z
--option=Z
$invalid_variable_name Z
EOF
(
cur=should_be_ignored &&
__gitcomp_direct "$(cat expected)" &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__gitcomp - trailing space - options' '
test_gitcomp "--re" "--dry-run --reuse-message= --reedit-message=
--reset-author" <<-EOF
--reuse-message=Z
--reedit-message=Z
--reset-author Z
EOF
'
test_expect_success '__gitcomp - trailing space - config keys' '
test_gitcomp "br" "branch. branch.autosetupmerge
branch.autosetuprebase browser." <<-\EOF
branch.Z
branch.autosetupmerge Z
branch.autosetuprebase Z
browser.Z
EOF
'
test_expect_success '__gitcomp - option parameter' '
test_gitcomp "--strategy=re" "octopus ours recursive resolve subtree" \
"" "re" <<-\EOF
recursive Z
resolve Z
EOF
'
test_expect_success '__gitcomp - prefix' '
test_gitcomp "branch.me" "remote merge mergeoptions rebase" \
"branch.maint." "me" <<-\EOF
branch.maint.merge Z
branch.maint.mergeoptions Z
EOF
'
test_expect_success '__gitcomp - suffix' '
test_gitcomp "branch.me" "master maint next seen" "branch." \
"ma" "." <<-\EOF
branch.master.Z
branch.maint.Z
EOF
'
completion: collapse extra --no-.. options The commands that make use of --git-completion-helper feature could now produce a lot of --no-xxx options that a command can take. This in many case could nearly double the amount of completable options, using more screen estate and also harder to search for the wanted option. This patch attempts to mitigate that by collapsing extra --no- options, the ones that are added by --git-completion-helper and not in original struct option arrays. The "--no-..." option will be displayed in this case to hint about more options, e.g. > ~/w/git $ git clone -- --bare --origin= --branch= --progress --checkout --quiet --config= --recurse-submodules --depth= --reference= --dissociate --reference-if-able= --filter= --separate-git-dir= --hardlinks --shallow-exclude= --ipv4 --shallow-since= --ipv6 --shallow-submodules --jobs= --shared --local --single-branch --mirror --tags --no-... --template= --no-checkout --upload-pack= --no-hardlinks --verbose --no-tags and when you complete it with --no-<tab>, all negative options will be presented: > ~/w/git $ git clone --no- --no-bare --no-quiet --no-branch --no-recurse-submodules --no-checkout --no-reference --no-config --no-reference-if-able --no-depth --no-separate-git-dir --no-dissociate --no-shallow-exclude --no-filter --no-shallow-since --no-hardlinks --no-shallow-submodules --no-ipv4 --no-shared --no-ipv6 --no-single-branch --no-jobs --no-tags --no-local --no-template --no-mirror --no-upload-pack --no-origin --no-verbose --no-progress Corner case: to make sure that people will never accidentally complete the fake option "--no-..." there must be one real --no- in the first complete listing even if it's not from the original struct option. PS. This could could be made simpler with ";&" to fall through from "--no-*" block and share the code but ";&" is not available on bash-3 (i.e. Mac) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-06 11:41:39 +02:00
test_expect_success '__gitcomp - ignore optional negative options' '
test_gitcomp "--" "--abc --def --no-one -- --no-two" <<-\EOF
--abc Z
--def Z
--no-one Z
--no-... Z
EOF
'
test_expect_success '__gitcomp - ignore/narrow optional negative options' '
test_gitcomp "--a" "--abc --abcdef --no-one -- --no-two" <<-\EOF
--abc Z
--abcdef Z
EOF
'
test_expect_success '__gitcomp - ignore/narrow optional negative options' '
test_gitcomp "--n" "--abc --def --no-one -- --no-two" <<-\EOF
--no-one Z
--no-... Z
EOF
'
test_expect_success '__gitcomp - expand all negative options' '
test_gitcomp "--no-" "--abc --def --no-one -- --no-two" <<-\EOF
--no-one Z
--no-two Z
EOF
'
test_expect_success '__gitcomp - expand/narrow all negative options' '
test_gitcomp "--no-o" "--abc --def --no-one -- --no-two" <<-\EOF
--no-one Z
EOF
'
test_expect_success '__gitcomp - equal skip' '
test_gitcomp "--option=" "--option=" <<-\EOF &&
EOF
test_gitcomp "option=" "option=" <<-\EOF
EOF
'
test_expect_success '__gitcomp - doesnt fail because of invalid variable name' '
__gitcomp "$invalid_variable_name"
'
read -r -d "" refs <<-\EOF
main
maint
next
seen
EOF
test_expect_success '__gitcomp_nl - trailing space' '
test_gitcomp_nl "m" "$refs" <<-EOF
main Z
maint Z
EOF
'
test_expect_success '__gitcomp_nl - prefix' '
test_gitcomp_nl "--fixup=m" "$refs" "--fixup=" "m" <<-EOF
--fixup=main Z
--fixup=maint Z
EOF
'
test_expect_success '__gitcomp_nl - suffix' '
test_gitcomp_nl "branch.ma" "$refs" "branch." "ma" "." <<-\EOF
branch.main.Z
branch.maint.Z
EOF
'
test_expect_success '__gitcomp_nl - no suffix' '
test_gitcomp_nl "ma" "$refs" "" "ma" "" <<-\EOF
mainZ
maintZ
EOF
'
test_expect_success '__gitcomp_nl - doesnt fail because of invalid variable name' '
__gitcomp_nl "$invalid_variable_name"
'
test_expect_success '__git_remotes - list remotes from $GIT_DIR/remotes and from config file' '
cat >expect <<-EOF &&
remote_from_file_1
remote_from_file_2
remote_in_config_1
remote_in_config_2
EOF
test_when_finished "rm -rf .git/remotes" &&
mkdir -p .git/remotes &&
>.git/remotes/remote_from_file_1 &&
>.git/remotes/remote_from_file_2 &&
test_when_finished "git remote remove remote_in_config_1" &&
git remote add remote_in_config_1 git://remote_1 &&
test_when_finished "git remote remove remote_in_config_2" &&
git remote add remote_in_config_2 git://remote_2 &&
(
__git_remotes >actual
) &&
test_cmp expect actual
'
test_expect_success '__git_is_configured_remote' '
test_when_finished "git remote remove remote_1" &&
git remote add remote_1 git://remote_1 &&
test_when_finished "git remote remove remote_2" &&
git remote add remote_2 git://remote_2 &&
(
verbose __git_is_configured_remote remote_2 &&
test_must_fail __git_is_configured_remote non-existent
)
'
test_expect_success 'setup for ref completion' '
git commit --allow-empty -m initial &&
git branch -M main &&
git branch matching-branch &&
git tag matching-tag &&
(
cd otherrepo &&
git commit --allow-empty -m initial &&
git branch -m main main-in-other &&
git branch branch-in-other &&
git tag tag-in-other
) &&
git remote add other "$ROOT/otherrepo/.git" &&
git fetch --no-tags other &&
rm -f .git/FETCH_HEAD &&
git init thirdrepo
'
test_expect_success '__git_refs - simple' '
cat >expected <<-EOF &&
HEAD
main
matching-branch
other/branch-in-other
other/main-in-other
matching-tag
EOF
(
cur= &&
__git_refs >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - full refs' '
cat >expected <<-EOF &&
refs/heads/main
refs/heads/matching-branch
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
refs/remotes/other/branch-in-other
refs/remotes/other/main-in-other
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
refs/tags/matching-tag
EOF
(
cur=refs/heads/ &&
__git_refs >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - repo given on the command line' '
cat >expected <<-EOF &&
HEAD
branch-in-other
main-in-other
tag-in-other
EOF
(
__git_dir="$ROOT/otherrepo/.git" &&
cur= &&
__git_refs >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - remote on local file system' '
cat >expected <<-EOF &&
HEAD
branch-in-other
main-in-other
tag-in-other
EOF
(
cur= &&
__git_refs otherrepo >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - remote on local file system - full refs' '
cat >expected <<-EOF &&
refs/heads/branch-in-other
refs/heads/main-in-other
refs/tags/tag-in-other
EOF
(
cur=refs/ &&
__git_refs otherrepo >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - configured remote' '
cat >expected <<-EOF &&
HEAD
branch-in-other
main-in-other
EOF
(
cur= &&
__git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - configured remote - full refs' '
cat >expected <<-EOF &&
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
HEAD
refs/heads/branch-in-other
refs/heads/main-in-other
refs/tags/tag-in-other
EOF
(
cur=refs/ &&
__git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - configured remote - repo given on the command line' '
cat >expected <<-EOF &&
HEAD
branch-in-other
main-in-other
EOF
(
cd thirdrepo &&
__git_dir="$ROOT/.git" &&
cur= &&
__git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - configured remote - full refs - repo given on the command line' '
cat >expected <<-EOF &&
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
HEAD
refs/heads/branch-in-other
refs/heads/main-in-other
refs/tags/tag-in-other
EOF
(
cd thirdrepo &&
__git_dir="$ROOT/.git" &&
cur=refs/ &&
__git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - configured remote - remote name matches a directory' '
cat >expected <<-EOF &&
HEAD
branch-in-other
main-in-other
EOF
mkdir other &&
test_when_finished "rm -rf other" &&
(
cur= &&
__git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
completion: list short refs from a remote given as a URL e832f5c09680 (completion: avoid ls-remote in certain scenarios, 2013-05-28) turned a 'git ls-remote <remote>' query into a 'git for-each-ref refs/remotes/<remote>/' to improve responsiveness of remote refs completion by avoiding potential network communication. However, it inadvertently made impossible to complete short refs from a remote given as a URL, e.g. 'git fetch git://server.com/repo.git <TAB>', because there is, of course, no such thing as 'refs/remotes/git://server.com/repo.git'. Since the previous commit we tell apart configured remotes, i.e. those that can have a hierarchy under 'refs/remotes/', from others that don't, including remotes given as URL, so we know when we can't use the faster 'git for-each-ref'-based approach. Resurrect the old, pre-e832f5c09680 'git ls-remote'-based code for the latter case to support listing short refs from remotes given as a URL. The code is slightly updated from the original to - take into account the path to the repository given on the command line (if any), and - omit 'ORIG_HEAD' from the query, as 'git ls-remote' will never list it anyway. When the remote given to __git_refs() doesn't exist, then it will be handled by this resurrected 'git ls-remote' query. This code path doesn't list 'HEAD' unconditionally, which has the nice side effect of fixing two more expected test failures. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:20 +01:00
test_expect_success '__git_refs - URL remote' '
cat >expected <<-EOF &&
HEAD
branch-in-other
main-in-other
tag-in-other
EOF
(
cur= &&
__git_refs "file://$ROOT/otherrepo/.git" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - URL remote - full refs' '
cat >expected <<-EOF &&
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
HEAD
refs/heads/branch-in-other
refs/heads/main-in-other
refs/tags/tag-in-other
EOF
(
cur=refs/ &&
__git_refs "file://$ROOT/otherrepo/.git" >"$actual"
) &&
test_cmp expected "$actual"
'
completion: list short refs from a remote given as a URL e832f5c09680 (completion: avoid ls-remote in certain scenarios, 2013-05-28) turned a 'git ls-remote <remote>' query into a 'git for-each-ref refs/remotes/<remote>/' to improve responsiveness of remote refs completion by avoiding potential network communication. However, it inadvertently made impossible to complete short refs from a remote given as a URL, e.g. 'git fetch git://server.com/repo.git <TAB>', because there is, of course, no such thing as 'refs/remotes/git://server.com/repo.git'. Since the previous commit we tell apart configured remotes, i.e. those that can have a hierarchy under 'refs/remotes/', from others that don't, including remotes given as URL, so we know when we can't use the faster 'git for-each-ref'-based approach. Resurrect the old, pre-e832f5c09680 'git ls-remote'-based code for the latter case to support listing short refs from remotes given as a URL. The code is slightly updated from the original to - take into account the path to the repository given on the command line (if any), and - omit 'ORIG_HEAD' from the query, as 'git ls-remote' will never list it anyway. When the remote given to __git_refs() doesn't exist, then it will be handled by this resurrected 'git ls-remote' query. This code path doesn't list 'HEAD' unconditionally, which has the nice side effect of fixing two more expected test failures. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:20 +01:00
test_expect_success '__git_refs - non-existing remote' '
(
cur= &&
__git_refs non-existing >"$actual"
) &&
test_must_be_empty "$actual"
'
test_expect_success '__git_refs - non-existing remote - full refs' '
(
cur=refs/ &&
__git_refs non-existing >"$actual"
) &&
test_must_be_empty "$actual"
'
completion: list short refs from a remote given as a URL e832f5c09680 (completion: avoid ls-remote in certain scenarios, 2013-05-28) turned a 'git ls-remote <remote>' query into a 'git for-each-ref refs/remotes/<remote>/' to improve responsiveness of remote refs completion by avoiding potential network communication. However, it inadvertently made impossible to complete short refs from a remote given as a URL, e.g. 'git fetch git://server.com/repo.git <TAB>', because there is, of course, no such thing as 'refs/remotes/git://server.com/repo.git'. Since the previous commit we tell apart configured remotes, i.e. those that can have a hierarchy under 'refs/remotes/', from others that don't, including remotes given as URL, so we know when we can't use the faster 'git for-each-ref'-based approach. Resurrect the old, pre-e832f5c09680 'git ls-remote'-based code for the latter case to support listing short refs from remotes given as a URL. The code is slightly updated from the original to - take into account the path to the repository given on the command line (if any), and - omit 'ORIG_HEAD' from the query, as 'git ls-remote' will never list it anyway. When the remote given to __git_refs() doesn't exist, then it will be handled by this resurrected 'git ls-remote' query. This code path doesn't list 'HEAD' unconditionally, which has the nice side effect of fixing two more expected test failures. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:20 +01:00
test_expect_success '__git_refs - non-existing URL remote' '
(
cur= &&
__git_refs "file://$ROOT/non-existing" >"$actual"
) &&
test_must_be_empty "$actual"
'
test_expect_success '__git_refs - non-existing URL remote - full refs' '
(
cur=refs/ &&
__git_refs "file://$ROOT/non-existing" >"$actual"
) &&
test_must_be_empty "$actual"
'
test_expect_success '__git_refs - not in a git repository' '
(
GIT_CEILING_DIRECTORIES="$ROOT" &&
export GIT_CEILING_DIRECTORIES &&
cd subdir &&
cur= &&
__git_refs >"$actual"
) &&
test_must_be_empty "$actual"
'
test_expect_success '__git_refs - unique remote branches for git checkout DWIMery' '
cat >expected <<-EOF &&
HEAD
main
matching-branch
other/ambiguous
other/branch-in-other
other/main-in-other
remote/ambiguous
remote/branch-in-remote
matching-tag
branch-in-other
branch-in-remote
main-in-other
EOF
for remote_ref in refs/remotes/other/ambiguous \
refs/remotes/remote/ambiguous \
refs/remotes/remote/branch-in-remote
do
git update-ref $remote_ref main &&
test_when_finished "git update-ref -d $remote_ref" || return 1
done &&
(
cur= &&
__git_refs "" 1 >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - after --opt=' '
cat >expected <<-EOF &&
HEAD
main
matching-branch
other/branch-in-other
other/main-in-other
matching-tag
EOF
(
cur="--opt=" &&
__git_refs "" "" "" "" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - after --opt= - full refs' '
cat >expected <<-EOF &&
refs/heads/main
refs/heads/matching-branch
refs/remotes/other/branch-in-other
refs/remotes/other/main-in-other
refs/tags/matching-tag
EOF
(
cur="--opt=refs/" &&
__git_refs "" "" "" refs/ >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git refs - excluding refs' '
cat >expected <<-EOF &&
^HEAD
^main
^matching-branch
^other/branch-in-other
^other/main-in-other
^matching-tag
EOF
(
cur=^ &&
__git_refs >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git refs - excluding full refs' '
cat >expected <<-EOF &&
^refs/heads/main
^refs/heads/matching-branch
^refs/remotes/other/branch-in-other
^refs/remotes/other/main-in-other
^refs/tags/matching-tag
EOF
(
cur=^refs/ &&
__git_refs >"$actual"
) &&
test_cmp expected "$actual"
'
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
test_expect_success 'setup for filtering matching refs' '
git branch matching/branch &&
git tag matching/tag &&
git -C otherrepo branch matching/branch-in-other &&
git fetch --no-tags other &&
rm -f .git/FETCH_HEAD
'
test_expect_success '__git_refs - do not filter refs unless told so' '
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
cat >expected <<-EOF &&
HEAD
main
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
matching-branch
matching/branch
other/branch-in-other
other/main-in-other
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
other/matching/branch-in-other
matching-tag
matching/tag
EOF
(
cur=main &&
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
__git_refs >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - only matching refs' '
cat >expected <<-EOF &&
matching-branch
matching/branch
matching-tag
matching/tag
EOF
(
cur=mat &&
__git_refs "" "" "" "$cur" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - only matching refs - full refs' '
cat >expected <<-EOF &&
refs/heads/matching-branch
refs/heads/matching/branch
EOF
(
cur=refs/heads/mat &&
__git_refs "" "" "" "$cur" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - only matching refs - remote on local file system' '
cat >expected <<-EOF &&
main-in-other
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
matching/branch-in-other
EOF
(
cur=ma &&
__git_refs otherrepo "" "" "$cur" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - only matching refs - configured remote' '
cat >expected <<-EOF &&
main-in-other
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
matching/branch-in-other
EOF
(
cur=ma &&
__git_refs other "" "" "$cur" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - only matching refs - remote - full refs' '
cat >expected <<-EOF &&
refs/heads/main-in-other
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
refs/heads/matching/branch-in-other
EOF
(
cur=refs/heads/ma &&
__git_refs other "" "" "$cur" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - only matching refs - checkout DWIMery' '
cat >expected <<-EOF &&
matching-branch
matching/branch
matching-tag
matching/tag
matching/branch-in-other
EOF
for remote_ref in refs/remotes/other/ambiguous \
refs/remotes/remote/ambiguous \
refs/remotes/remote/branch-in-remote
do
git update-ref $remote_ref main &&
test_when_finished "git update-ref -d $remote_ref" || return 1
completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:18 +01:00
done &&
(
cur=mat &&
__git_refs "" 1 "" "$cur" >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success 'teardown after filtering matching refs' '
git branch -d matching/branch &&
git tag -d matching/tag &&
git update-ref -d refs/remotes/other/matching/branch-in-other &&
git -C otherrepo branch -D matching/branch-in-other
'
test_expect_success '__git_refs - for-each-ref format specifiers in prefix' '
completion: fill COMPREPLY directly when completing refs __gitcomp_nl() iterates over all the possible completion words it gets as argument - filtering matching words, - appending a trailing space to each matching word (in all but two cases), - prepending a prefix to each matching word (when completing words after e.g. '--option=<TAB>' or 'master..<TAB>'), and - adding each matching word to the COMPREPLY array. This takes a while when a lot of refs are passed to __gitcomp_nl(). The previous changes in this series ensure that __git_refs() lists only refs matching the current word to be completed, making a second filtering in __gitcomp_nl() redundant. Adding the necessary prefix and suffix could be done in __git_refs() as well: - When refs come from 'git for-each-ref', then that prefix and suffix could be added much more efficiently using a 'git for-each-ref' format containing said prefix and suffix. Care should be taken, though, because that prefix might contain 'for-each-ref' format specifiers as part of the left hand side of a '..' range or '...' symmetric difference notation or fetch/push/etc. refspec, e.g. 'git log "evil-%(refname)..br<TAB>'. Doubling every '%' in the prefix will prevent 'git for-each-ref' from interpolating any of those contained specifiers. - When refs come from 'git ls-remote', then that prefix and suffix can be added in the shell loop that has to process 'git ls-remote's output anyway. - Finally, the prefix and suffix can be added to that handful of potentially matching symbolic and pseudo refs right away in the shell loop listing them. And then all what is still left to do is to assign a bunch of newline-separated words to a shell array, which can be done without a shell loop iterating over each word, basically making all of __gitcomp_nl() unnecessary for refs completion. Add the helper function __gitcomp_direct() to fill the COMPREPLY array with prefiltered and preprocessed words without any additional processing, without a shell loop, with just one single compound assignment. Modify __git_refs() to accept prefix and suffix parameters and add them to each and every listed ref as described above. Modify __git_complete_refs() to pass the prefix and suffix parameters to __git_refs() and to feed __git_refs()'s output to __gitcomp_direct() instead of __gitcomp_nl(). This speeds up refs completion when there are a lot of refs matching the current word to be completed. Listing all branches for completion in a repo with 100k local branches, all packed, best of five: On Linux, near the beginning of this series, for reference: $ time __git_complete_refs real 0m2.028s user 0m1.692s sys 0m0.344s Before this patch: real 0m1.135s user 0m1.112s sys 0m0.024s After: real 0m0.367s user 0m0.352s sys 0m0.020s On Windows, near the beginning: real 0m13.078s user 0m1.609s sys 0m0.060s Before this patch: real 0m2.093s user 0m1.641s sys 0m0.060s After: real 0m0.683s user 0m0.203s sys 0m0.076s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:22 +01:00
cat >expected <<-EOF &&
evil-%%-%42-%(refname)..main
completion: fill COMPREPLY directly when completing refs __gitcomp_nl() iterates over all the possible completion words it gets as argument - filtering matching words, - appending a trailing space to each matching word (in all but two cases), - prepending a prefix to each matching word (when completing words after e.g. '--option=<TAB>' or 'master..<TAB>'), and - adding each matching word to the COMPREPLY array. This takes a while when a lot of refs are passed to __gitcomp_nl(). The previous changes in this series ensure that __git_refs() lists only refs matching the current word to be completed, making a second filtering in __gitcomp_nl() redundant. Adding the necessary prefix and suffix could be done in __git_refs() as well: - When refs come from 'git for-each-ref', then that prefix and suffix could be added much more efficiently using a 'git for-each-ref' format containing said prefix and suffix. Care should be taken, though, because that prefix might contain 'for-each-ref' format specifiers as part of the left hand side of a '..' range or '...' symmetric difference notation or fetch/push/etc. refspec, e.g. 'git log "evil-%(refname)..br<TAB>'. Doubling every '%' in the prefix will prevent 'git for-each-ref' from interpolating any of those contained specifiers. - When refs come from 'git ls-remote', then that prefix and suffix can be added in the shell loop that has to process 'git ls-remote's output anyway. - Finally, the prefix and suffix can be added to that handful of potentially matching symbolic and pseudo refs right away in the shell loop listing them. And then all what is still left to do is to assign a bunch of newline-separated words to a shell array, which can be done without a shell loop iterating over each word, basically making all of __gitcomp_nl() unnecessary for refs completion. Add the helper function __gitcomp_direct() to fill the COMPREPLY array with prefiltered and preprocessed words without any additional processing, without a shell loop, with just one single compound assignment. Modify __git_refs() to accept prefix and suffix parameters and add them to each and every listed ref as described above. Modify __git_complete_refs() to pass the prefix and suffix parameters to __git_refs() and to feed __git_refs()'s output to __gitcomp_direct() instead of __gitcomp_nl(). This speeds up refs completion when there are a lot of refs matching the current word to be completed. Listing all branches for completion in a repo with 100k local branches, all packed, best of five: On Linux, near the beginning of this series, for reference: $ time __git_complete_refs real 0m2.028s user 0m1.692s sys 0m0.344s Before this patch: real 0m1.135s user 0m1.112s sys 0m0.024s After: real 0m0.367s user 0m0.352s sys 0m0.020s On Windows, near the beginning: real 0m13.078s user 0m1.609s sys 0m0.060s Before this patch: real 0m2.093s user 0m1.641s sys 0m0.060s After: real 0m0.683s user 0m0.203s sys 0m0.076s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:22 +01:00
EOF
(
cur="evil-%%-%42-%(refname)..mai" &&
__git_refs "" "" "evil-%%-%42-%(refname).." mai >"$actual"
completion: fill COMPREPLY directly when completing refs __gitcomp_nl() iterates over all the possible completion words it gets as argument - filtering matching words, - appending a trailing space to each matching word (in all but two cases), - prepending a prefix to each matching word (when completing words after e.g. '--option=<TAB>' or 'master..<TAB>'), and - adding each matching word to the COMPREPLY array. This takes a while when a lot of refs are passed to __gitcomp_nl(). The previous changes in this series ensure that __git_refs() lists only refs matching the current word to be completed, making a second filtering in __gitcomp_nl() redundant. Adding the necessary prefix and suffix could be done in __git_refs() as well: - When refs come from 'git for-each-ref', then that prefix and suffix could be added much more efficiently using a 'git for-each-ref' format containing said prefix and suffix. Care should be taken, though, because that prefix might contain 'for-each-ref' format specifiers as part of the left hand side of a '..' range or '...' symmetric difference notation or fetch/push/etc. refspec, e.g. 'git log "evil-%(refname)..br<TAB>'. Doubling every '%' in the prefix will prevent 'git for-each-ref' from interpolating any of those contained specifiers. - When refs come from 'git ls-remote', then that prefix and suffix can be added in the shell loop that has to process 'git ls-remote's output anyway. - Finally, the prefix and suffix can be added to that handful of potentially matching symbolic and pseudo refs right away in the shell loop listing them. And then all what is still left to do is to assign a bunch of newline-separated words to a shell array, which can be done without a shell loop iterating over each word, basically making all of __gitcomp_nl() unnecessary for refs completion. Add the helper function __gitcomp_direct() to fill the COMPREPLY array with prefiltered and preprocessed words without any additional processing, without a shell loop, with just one single compound assignment. Modify __git_refs() to accept prefix and suffix parameters and add them to each and every listed ref as described above. Modify __git_complete_refs() to pass the prefix and suffix parameters to __git_refs() and to feed __git_refs()'s output to __gitcomp_direct() instead of __gitcomp_nl(). This speeds up refs completion when there are a lot of refs matching the current word to be completed. Listing all branches for completion in a repo with 100k local branches, all packed, best of five: On Linux, near the beginning of this series, for reference: $ time __git_complete_refs real 0m2.028s user 0m1.692s sys 0m0.344s Before this patch: real 0m1.135s user 0m1.112s sys 0m0.024s After: real 0m0.367s user 0m0.352s sys 0m0.020s On Windows, near the beginning: real 0m13.078s user 0m1.609s sys 0m0.060s Before this patch: real 0m2.093s user 0m1.641s sys 0m0.060s After: real 0m0.683s user 0m0.203s sys 0m0.076s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:22 +01:00
) &&
test_cmp expected "$actual"
'
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
test_expect_success '__git_complete_refs - simple' '
sed -e "s/Z$//" >expected <<-EOF &&
HEAD Z
main Z
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
matching-branch Z
other/branch-in-other Z
other/main-in-other Z
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
matching-tag Z
EOF
(
cur= &&
__git_complete_refs &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_refs - matching' '
sed -e "s/Z$//" >expected <<-EOF &&
matching-branch Z
matching-tag Z
EOF
(
cur=mat &&
__git_complete_refs &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_refs - remote' '
sed -e "s/Z$//" >expected <<-EOF &&
HEAD Z
branch-in-other Z
main-in-other Z
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
EOF
(
cur= &&
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
__git_complete_refs --remote=other &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_refs - track' '
sed -e "s/Z$//" >expected <<-EOF &&
HEAD Z
main Z
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
matching-branch Z
other/branch-in-other Z
other/main-in-other Z
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
matching-tag Z
branch-in-other Z
main-in-other Z
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
EOF
(
cur= &&
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
__git_complete_refs --track &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_refs - current word' '
sed -e "s/Z$//" >expected <<-EOF &&
matching-branch Z
matching-tag Z
EOF
(
cur="--option=mat" &&
__git_complete_refs --cur="${cur#*=}" &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_refs - prefix' '
sed -e "s/Z$//" >expected <<-EOF &&
v1.0..matching-branch Z
v1.0..matching-tag Z
EOF
(
cur=v1.0..mat &&
__git_complete_refs --pfx=v1.0.. --cur=mat &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_refs - suffix' '
cat >expected <<-EOF &&
HEAD.
main.
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
matching-branch.
other/branch-in-other.
other/main-in-other.
completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:12 +01:00
matching-tag.
EOF
(
cur= &&
__git_complete_refs --sfx=. &&
print_comp
) &&
test_cmp expected out
'
completion: support completing fully qualified non-fast-forward refspecs After 'git fetch <remote> <TAB>' our completion script offers refspecs that will fetch to a local branch with the same name as in the remote repository, e.g. 'master:master'. This also completes non-fast-forward refspecs, i.e. after a '+' prefix like '+master:master', and fully qualified refspecs, e.g. 'refs/heads/master:refs/heads/master'. However, it does not complete non-fast-forward fully qualified refspecs (or fully qualified refspecs following any other prefix, e.g. '--option=', though currently no git command supports such an option, but third party git commands might). These refspecs are listed by the __git_refs2() function, which is just a thin wrapper iterating over __git_refs()'s output, turning each listed ref into a refspec. Now, it's certainly possible to modify __git_refs2() and its callsite to pass an extra parameter containing only the ref part of the current word to be completed (to follow suit of the previous commit) to deal with prefixed fully qualified refspecs as well. Unfortunately, keeping the current behavior unchanged in the "no extra parameter" case brings in a bit of subtlety, which makes the resulting code ugly and compelled me to write a 8-line long comment in the proof of concept. Not good. However, since the callsite has to be modified for proper functioning anyway, we might as well leave __git_refs2() as is and introduce a new helper function without backwards compatibility concerns. Add the new function __git_complete_fetch_refspecs() that has all the necessary parameters to do the right thing in all cases mentioned above, including non-fast-forward fully qualified refspecs. This new function can also easier benefit from optimizations coming later in this patch series. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:14 +01:00
test_expect_success '__git_complete_fetch_refspecs - simple' '
sed -e "s/Z$//" >expected <<-EOF &&
HEAD:HEAD Z
branch-in-other:branch-in-other Z
main-in-other:main-in-other Z
completion: support completing fully qualified non-fast-forward refspecs After 'git fetch <remote> <TAB>' our completion script offers refspecs that will fetch to a local branch with the same name as in the remote repository, e.g. 'master:master'. This also completes non-fast-forward refspecs, i.e. after a '+' prefix like '+master:master', and fully qualified refspecs, e.g. 'refs/heads/master:refs/heads/master'. However, it does not complete non-fast-forward fully qualified refspecs (or fully qualified refspecs following any other prefix, e.g. '--option=', though currently no git command supports such an option, but third party git commands might). These refspecs are listed by the __git_refs2() function, which is just a thin wrapper iterating over __git_refs()'s output, turning each listed ref into a refspec. Now, it's certainly possible to modify __git_refs2() and its callsite to pass an extra parameter containing only the ref part of the current word to be completed (to follow suit of the previous commit) to deal with prefixed fully qualified refspecs as well. Unfortunately, keeping the current behavior unchanged in the "no extra parameter" case brings in a bit of subtlety, which makes the resulting code ugly and compelled me to write a 8-line long comment in the proof of concept. Not good. However, since the callsite has to be modified for proper functioning anyway, we might as well leave __git_refs2() as is and introduce a new helper function without backwards compatibility concerns. Add the new function __git_complete_fetch_refspecs() that has all the necessary parameters to do the right thing in all cases mentioned above, including non-fast-forward fully qualified refspecs. This new function can also easier benefit from optimizations coming later in this patch series. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:14 +01:00
EOF
(
cur= &&
__git_complete_fetch_refspecs other &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_fetch_refspecs - matching' '
sed -e "s/Z$//" >expected <<-EOF &&
branch-in-other:branch-in-other Z
EOF
(
cur=br &&
__git_complete_fetch_refspecs other "" br &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_fetch_refspecs - prefix' '
sed -e "s/Z$//" >expected <<-EOF &&
+HEAD:HEAD Z
+branch-in-other:branch-in-other Z
+main-in-other:main-in-other Z
completion: support completing fully qualified non-fast-forward refspecs After 'git fetch <remote> <TAB>' our completion script offers refspecs that will fetch to a local branch with the same name as in the remote repository, e.g. 'master:master'. This also completes non-fast-forward refspecs, i.e. after a '+' prefix like '+master:master', and fully qualified refspecs, e.g. 'refs/heads/master:refs/heads/master'. However, it does not complete non-fast-forward fully qualified refspecs (or fully qualified refspecs following any other prefix, e.g. '--option=', though currently no git command supports such an option, but third party git commands might). These refspecs are listed by the __git_refs2() function, which is just a thin wrapper iterating over __git_refs()'s output, turning each listed ref into a refspec. Now, it's certainly possible to modify __git_refs2() and its callsite to pass an extra parameter containing only the ref part of the current word to be completed (to follow suit of the previous commit) to deal with prefixed fully qualified refspecs as well. Unfortunately, keeping the current behavior unchanged in the "no extra parameter" case brings in a bit of subtlety, which makes the resulting code ugly and compelled me to write a 8-line long comment in the proof of concept. Not good. However, since the callsite has to be modified for proper functioning anyway, we might as well leave __git_refs2() as is and introduce a new helper function without backwards compatibility concerns. Add the new function __git_complete_fetch_refspecs() that has all the necessary parameters to do the right thing in all cases mentioned above, including non-fast-forward fully qualified refspecs. This new function can also easier benefit from optimizations coming later in this patch series. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:14 +01:00
EOF
(
cur="+" &&
__git_complete_fetch_refspecs other "+" "" &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_fetch_refspecs - fully qualified' '
sed -e "s/Z$//" >expected <<-EOF &&
refs/heads/branch-in-other:refs/heads/branch-in-other Z
refs/heads/main-in-other:refs/heads/main-in-other Z
completion: support completing fully qualified non-fast-forward refspecs After 'git fetch <remote> <TAB>' our completion script offers refspecs that will fetch to a local branch with the same name as in the remote repository, e.g. 'master:master'. This also completes non-fast-forward refspecs, i.e. after a '+' prefix like '+master:master', and fully qualified refspecs, e.g. 'refs/heads/master:refs/heads/master'. However, it does not complete non-fast-forward fully qualified refspecs (or fully qualified refspecs following any other prefix, e.g. '--option=', though currently no git command supports such an option, but third party git commands might). These refspecs are listed by the __git_refs2() function, which is just a thin wrapper iterating over __git_refs()'s output, turning each listed ref into a refspec. Now, it's certainly possible to modify __git_refs2() and its callsite to pass an extra parameter containing only the ref part of the current word to be completed (to follow suit of the previous commit) to deal with prefixed fully qualified refspecs as well. Unfortunately, keeping the current behavior unchanged in the "no extra parameter" case brings in a bit of subtlety, which makes the resulting code ugly and compelled me to write a 8-line long comment in the proof of concept. Not good. However, since the callsite has to be modified for proper functioning anyway, we might as well leave __git_refs2() as is and introduce a new helper function without backwards compatibility concerns. Add the new function __git_complete_fetch_refspecs() that has all the necessary parameters to do the right thing in all cases mentioned above, including non-fast-forward fully qualified refspecs. This new function can also easier benefit from optimizations coming later in this patch series. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:14 +01:00
refs/tags/tag-in-other:refs/tags/tag-in-other Z
EOF
(
cur=refs/ &&
__git_complete_fetch_refspecs other "" refs/ &&
print_comp
) &&
test_cmp expected out
'
test_expect_success '__git_complete_fetch_refspecs - fully qualified & prefix' '
sed -e "s/Z$//" >expected <<-EOF &&
+refs/heads/branch-in-other:refs/heads/branch-in-other Z
+refs/heads/main-in-other:refs/heads/main-in-other Z
completion: support completing fully qualified non-fast-forward refspecs After 'git fetch <remote> <TAB>' our completion script offers refspecs that will fetch to a local branch with the same name as in the remote repository, e.g. 'master:master'. This also completes non-fast-forward refspecs, i.e. after a '+' prefix like '+master:master', and fully qualified refspecs, e.g. 'refs/heads/master:refs/heads/master'. However, it does not complete non-fast-forward fully qualified refspecs (or fully qualified refspecs following any other prefix, e.g. '--option=', though currently no git command supports such an option, but third party git commands might). These refspecs are listed by the __git_refs2() function, which is just a thin wrapper iterating over __git_refs()'s output, turning each listed ref into a refspec. Now, it's certainly possible to modify __git_refs2() and its callsite to pass an extra parameter containing only the ref part of the current word to be completed (to follow suit of the previous commit) to deal with prefixed fully qualified refspecs as well. Unfortunately, keeping the current behavior unchanged in the "no extra parameter" case brings in a bit of subtlety, which makes the resulting code ugly and compelled me to write a 8-line long comment in the proof of concept. Not good. However, since the callsite has to be modified for proper functioning anyway, we might as well leave __git_refs2() as is and introduce a new helper function without backwards compatibility concerns. Add the new function __git_complete_fetch_refspecs() that has all the necessary parameters to do the right thing in all cases mentioned above, including non-fast-forward fully qualified refspecs. This new function can also easier benefit from optimizations coming later in this patch series. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23 16:29:14 +01:00
+refs/tags/tag-in-other:refs/tags/tag-in-other Z
EOF
(
cur=+refs/ &&
__git_complete_fetch_refspecs other + refs/ &&
print_comp
) &&
test_cmp expected out
'
test_expect_success 'git switch - with no options, complete local branches and unique remote branch names for DWIM logic' '
completion: add test showing subpar git switch completion When provided with no options, git switch only allows switching between branches. The one exception to this is the "Do What I Mean" logic that allows a unique remote branch name to be interpreted as a request to create a branch of the same name that is tracking that remote branch. Unfortunately, the logic for the completion of git switch results in completing not just branch names, but also pseudorefs like HEAD, tags, and fully specified <remote>/<branch> references. For example, we currently complete the following: $git switch <TAB> HEAD branch-in-other master master-in-other matching-branch matching-tag other/branch-in-other other/master-in-other Indeed, if one were to attempt to use git switch with some of these provided options, git will reject the request: $git switch HEAD fatal: a branch is expected, got 'HEAD $git switch matching-tag fatal: a branch is expected, got tag 'matching-tag' $git switch other/branch-in-other fatal: a branch is expected, got remote branch 'other/branch-in-other' Ideally, git switch without options ought to complete only words which will be accepted. Without options, this means to list local branch names and the unique remote branch names without their remote name pre-pended. $git switch <TAB> branch-in-other master master-in-other matching-branch Add a test case that highlights this subpar completion. Also add a similar test for git checkout completion that shows that due to the complex nature of git checkout, it must complete all references. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:33 +02:00
test_completion "git switch " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
completion: add test showing subpar git switch completion When provided with no options, git switch only allows switching between branches. The one exception to this is the "Do What I Mean" logic that allows a unique remote branch name to be interpreted as a request to create a branch of the same name that is tracking that remote branch. Unfortunately, the logic for the completion of git switch results in completing not just branch names, but also pseudorefs like HEAD, tags, and fully specified <remote>/<branch> references. For example, we currently complete the following: $git switch <TAB> HEAD branch-in-other master master-in-other matching-branch matching-tag other/branch-in-other other/master-in-other Indeed, if one were to attempt to use git switch with some of these provided options, git will reject the request: $git switch HEAD fatal: a branch is expected, got 'HEAD $git switch matching-tag fatal: a branch is expected, got tag 'matching-tag' $git switch other/branch-in-other fatal: a branch is expected, got remote branch 'other/branch-in-other' Ideally, git switch without options ought to complete only words which will be accepted. Without options, this means to list local branch names and the unique remote branch names without their remote name pre-pended. $git switch <TAB> branch-in-other master master-in-other matching-branch Add a test case that highlights this subpar completion. Also add a similar test for git checkout completion that shows that due to the complex nature of git checkout, it must complete all references. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:33 +02:00
matching-branch Z
EOF
'
test_expect_success 'git checkout - completes refs and unique remote branches for DWIM' '
test_completion "git checkout " <<-\EOF
HEAD Z
branch-in-other Z
main Z
main-in-other Z
completion: add test showing subpar git switch completion When provided with no options, git switch only allows switching between branches. The one exception to this is the "Do What I Mean" logic that allows a unique remote branch name to be interpreted as a request to create a branch of the same name that is tracking that remote branch. Unfortunately, the logic for the completion of git switch results in completing not just branch names, but also pseudorefs like HEAD, tags, and fully specified <remote>/<branch> references. For example, we currently complete the following: $git switch <TAB> HEAD branch-in-other master master-in-other matching-branch matching-tag other/branch-in-other other/master-in-other Indeed, if one were to attempt to use git switch with some of these provided options, git will reject the request: $git switch HEAD fatal: a branch is expected, got 'HEAD $git switch matching-tag fatal: a branch is expected, got tag 'matching-tag' $git switch other/branch-in-other fatal: a branch is expected, got remote branch 'other/branch-in-other' Ideally, git switch without options ought to complete only words which will be accepted. Without options, this means to list local branch names and the unique remote branch names without their remote name pre-pended. $git switch <TAB> branch-in-other master master-in-other matching-branch Add a test case that highlights this subpar completion. Also add a similar test for git checkout completion that shows that due to the complex nature of git checkout, it must complete all references. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:33 +02:00
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
completion: add test showing subpar git switch completion When provided with no options, git switch only allows switching between branches. The one exception to this is the "Do What I Mean" logic that allows a unique remote branch name to be interpreted as a request to create a branch of the same name that is tracking that remote branch. Unfortunately, the logic for the completion of git switch results in completing not just branch names, but also pseudorefs like HEAD, tags, and fully specified <remote>/<branch> references. For example, we currently complete the following: $git switch <TAB> HEAD branch-in-other master master-in-other matching-branch matching-tag other/branch-in-other other/master-in-other Indeed, if one were to attempt to use git switch with some of these provided options, git will reject the request: $git switch HEAD fatal: a branch is expected, got 'HEAD $git switch matching-tag fatal: a branch is expected, got tag 'matching-tag' $git switch other/branch-in-other fatal: a branch is expected, got remote branch 'other/branch-in-other' Ideally, git switch without options ought to complete only words which will be accepted. Without options, this means to list local branch names and the unique remote branch names without their remote name pre-pended. $git switch <TAB> branch-in-other master master-in-other matching-branch Add a test case that highlights this subpar completion. Also add a similar test for git checkout completion that shows that due to the complex nature of git checkout, it must complete all references. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:33 +02:00
EOF
'
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
test_expect_success 'git switch - with --no-guess, complete only local branches' '
test_completion "git switch --no-guess " <<-\EOF
main Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
EOF
'
test_expect_success 'git switch - with GIT_COMPLETION_CHECKOUT_NO_GUESS=1, complete only local branches' '
GIT_COMPLETION_CHECKOUT_NO_GUESS=1 test_completion "git switch " <<-\EOF
main Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
EOF
'
test_expect_success 'git switch - --guess overrides GIT_COMPLETION_CHECKOUT_NO_GUESS=1, complete local branches and unique remote names for DWIM logic' '
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
GIT_COMPLETION_CHECKOUT_NO_GUESS=1 test_completion "git switch --guess " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
EOF
'
test_expect_success 'git switch - a later --guess overrides previous --no-guess, complete local and remote unique branches for DWIM' '
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
test_completion "git switch --no-guess --guess " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
EOF
'
completion: improve handling of DWIM mode for switch/checkout A new helper, __git_find_last_on_cmdline is introduced, similar to the already existing __git_find_on_cmdline, but which operates in reverse, finding the *last* matching word of the provided wordlist. Use this in a new __git_checkout_default_dwim_mode() function that will determine when to enable listing of DWIM remote branches. The __git_find_last_on_cmdline() function is used to determine which --guess or --no-guess is in effect. If either one is provided, then we unconditionally enable or disable the DWIM mode based on the last provided option. If neither --guess nor --no-guess is provided, then we check for --no-track, and finally for GIT_COMPLETION_CHECKOUT_NO_GUESS=1. This function is then used in _git_switch and _git_checkout to improve the handling for when we enable listing of these DWIM remote branches. This new logic is more robust, as we will correctly identify superseded options, and ensure that both _git_switch and _git_checkout enable DWIM in similar ways. We can now update a few tests to indicate they pass. A few of the tests previously added to highlight issues with the old DWIM logic still fail. This is because of a separate issue related to the default completion behavior of git switch, which will be addressed in a future change. Additionally, due to this change, a few tests for the -b/-B handling of git checkout now fail. This is a minor regression, and will be fixed by a following change that improves the overall handling of -b/-B. Mark these tests as known breakages for now. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:43 +02:00
test_expect_success 'git switch - a later --no-guess overrides previous --guess, complete only local branches' '
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
test_completion "git switch --guess --no-guess " <<-\EOF
main Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
EOF
'
test_expect_success 'git checkout - with GIT_COMPLETION_NO_GUESS=1 only completes refs' '
GIT_COMPLETION_CHECKOUT_NO_GUESS=1 test_completion "git checkout " <<-\EOF
HEAD Z
main Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
EOF
'
completion: improve handling of DWIM mode for switch/checkout A new helper, __git_find_last_on_cmdline is introduced, similar to the already existing __git_find_on_cmdline, but which operates in reverse, finding the *last* matching word of the provided wordlist. Use this in a new __git_checkout_default_dwim_mode() function that will determine when to enable listing of DWIM remote branches. The __git_find_last_on_cmdline() function is used to determine which --guess or --no-guess is in effect. If either one is provided, then we unconditionally enable or disable the DWIM mode based on the last provided option. If neither --guess nor --no-guess is provided, then we check for --no-track, and finally for GIT_COMPLETION_CHECKOUT_NO_GUESS=1. This function is then used in _git_switch and _git_checkout to improve the handling for when we enable listing of these DWIM remote branches. This new logic is more robust, as we will correctly identify superseded options, and ensure that both _git_switch and _git_checkout enable DWIM in similar ways. We can now update a few tests to indicate they pass. A few of the tests previously added to highlight issues with the old DWIM logic still fail. This is because of a separate issue related to the default completion behavior of git switch, which will be addressed in a future change. Additionally, due to this change, a few tests for the -b/-B handling of git checkout now fail. This is a minor regression, and will be fixed by a following change that improves the overall handling of -b/-B. Mark these tests as known breakages for now. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:43 +02:00
test_expect_success 'git checkout - --guess overrides GIT_COMPLETION_NO_GUESS=1, complete refs and unique remote branches for DWIM' '
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
GIT_COMPLETION_CHECKOUT_NO_GUESS=1 test_completion "git checkout --guess " <<-\EOF
HEAD Z
branch-in-other Z
main Z
main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
EOF
'
test_expect_success 'git checkout - with --no-guess, only completes refs' '
test_completion "git checkout --no-guess " <<-\EOF
HEAD Z
main Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
EOF
'
completion: improve handling of DWIM mode for switch/checkout A new helper, __git_find_last_on_cmdline is introduced, similar to the already existing __git_find_on_cmdline, but which operates in reverse, finding the *last* matching word of the provided wordlist. Use this in a new __git_checkout_default_dwim_mode() function that will determine when to enable listing of DWIM remote branches. The __git_find_last_on_cmdline() function is used to determine which --guess or --no-guess is in effect. If either one is provided, then we unconditionally enable or disable the DWIM mode based on the last provided option. If neither --guess nor --no-guess is provided, then we check for --no-track, and finally for GIT_COMPLETION_CHECKOUT_NO_GUESS=1. This function is then used in _git_switch and _git_checkout to improve the handling for when we enable listing of these DWIM remote branches. This new logic is more robust, as we will correctly identify superseded options, and ensure that both _git_switch and _git_checkout enable DWIM in similar ways. We can now update a few tests to indicate they pass. A few of the tests previously added to highlight issues with the old DWIM logic still fail. This is because of a separate issue related to the default completion behavior of git switch, which will be addressed in a future change. Additionally, due to this change, a few tests for the -b/-B handling of git checkout now fail. This is a minor regression, and will be fixed by a following change that improves the overall handling of -b/-B. Mark these tests as known breakages for now. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:43 +02:00
test_expect_success 'git checkout - a later --guess overrides previous --no-guess, complete refs and unique remote branches for DWIM' '
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
test_completion "git checkout --no-guess --guess " <<-\EOF
HEAD Z
branch-in-other Z
main Z
main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
EOF
'
test_expect_success 'git checkout - a later --no-guess overrides previous --guess, complete only refs' '
test_completion "git checkout --guess --no-guess " <<-\EOF
HEAD Z
main Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
completion: add tests showing subpar DWIM logic for switch/checkout When provided with a single argument that is the name of a remote branch that does not yet exist locally, both git switch and git checkout can interpret this as a request to create a local branch that tracks that remote branch. We call this behavior "Do What I Mean", or DWIM for short. To aid in using this DWIM, it makes sense for completion to list these unique remote branch names when completing possible arguments for git switch and git checkout. Indeed, both _git_checkout and _git_switch implement support for completing such DWIM branch names. In other words, in addition to the usual completions provided for git switch, this "DWIM" logic means completion will include the names of branches on remotes that are unique and thus there can be no ambiguity of which remote to track when creating the local branch. However, the DWIM logic is not always active. Many options, such as --no-guess, --no-track, and --track disable this DWIM logic, as they cause git switch and git checkout to behave in different modes. Additionally, some completion users do not wish to have tab completion include these remote names by default, and thus introduced GIT_COMPLETION_CHECKOUT_NO_GUESS as an optional way to configure the completion support to disable this feature of completion support. For this reason, _git_checkout and _git_switch have many rules about when to enable or disable completing of these remote refs. The two commands follow similar but not identical rules. Set aside the question of command modes that do not accept this DWIM logic (--track, -c, --orphan, --detach) for now. Thinking just about the main mode of git checkout and git switch, the following guidelines will help explain the basic rules we ought to support when deciding whether to list the remote branches for DWIM in completion. 1. if --guess is enabled, we should list DWIM remote branch names, even if something else would disable it 2. if --no-guess, --no-track or GIT_COMPLETION_CHECKOUT_NO_GUESS=1, then we should disable listing DWIM remote branch names. 3. Since the '--guess' option is a boolean option, a later --guess should override --no-guess, and a later --no-guess should override --guess. Putting all of these together, add some tests that highlight the expected behavior of this DWIM logic. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 20:10:34 +02:00
EOF
'
test_expect_success 'git checkout - with checkout.guess = false, only completes refs' '
test_config checkout.guess false &&
test_completion "git checkout " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with checkout.guess = true, completes refs and unique remote branches for DWIM' '
test_config checkout.guess true &&
test_completion "git checkout " <<-\EOF
HEAD Z
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - a later --guess overrides previous checkout.guess = false, complete refs and unique remote branches for DWIM' '
test_config checkout.guess false &&
test_completion "git checkout --guess " <<-\EOF
HEAD Z
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - a later --no-guess overrides previous checkout.guess = true, complete only refs' '
test_config checkout.guess true &&
test_completion "git checkout --no-guess " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with --detach, complete all references' '
test_completion "git switch --detach " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with --detach, complete only references' '
test_completion "git checkout --detach " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'setup sparse-checkout tests' '
# set up sparse-checkout repo
git init sparse-checkout &&
(
cd sparse-checkout &&
mkdir -p folder1/0/1 folder2/0 folder3 &&
touch folder1/0/1/t.txt &&
touch folder2/0/t.txt &&
touch folder3/t.txt &&
git add . &&
git commit -am "Initial commit"
)
'
test_expect_success 'sparse-checkout completes subcommands' '
test_completion "git sparse-checkout " <<-\EOF
list Z
init Z
set Z
add Z
reapply Z
disable Z
EOF
'
test_expect_success 'cone mode sparse-checkout completes directory names' '
# initialize sparse-checkout definitions
git -C sparse-checkout sparse-checkout set --cone folder1/0 folder3 &&
# test tab completion
(
cd sparse-checkout &&
test_completion "git sparse-checkout set f" <<-\EOF
folder1/
folder2/
folder3/
EOF
) &&
(
cd sparse-checkout &&
test_completion "git sparse-checkout set folder1/" <<-\EOF
folder1/0/
EOF
) &&
(
cd sparse-checkout &&
test_completion "git sparse-checkout set folder1/0/" <<-\EOF
folder1/0/1/
EOF
) &&
(
cd sparse-checkout/folder1 &&
test_completion "git sparse-checkout add 0" <<-\EOF
0/
EOF
)
'
test_expect_success 'cone mode sparse-checkout completes directory names with spaces and accents' '
# reset sparse-checkout
git -C sparse-checkout sparse-checkout disable &&
(
cd sparse-checkout &&
mkdir "directory with spaces" &&
mkdir "directory-with-áccent" &&
>"directory with spaces/randomfile" &&
>"directory-with-áccent/randomfile" &&
git add . &&
git commit -m "Add directory with spaces and directory with accent" &&
git sparse-checkout set --cone "directory with spaces" \
"directory-with-áccent" &&
test_completion "git sparse-checkout add dir" <<-\EOF &&
directory with spaces/
directory-with-áccent/
EOF
rm -rf "directory with spaces" &&
rm -rf "directory-with-áccent" &&
git add . &&
git commit -m "Remove directory with spaces and directory with accent"
)
'
# use FUNNYNAMES to avoid running on Windows, which doesn't permit backslashes or tabs in paths
test_expect_success FUNNYNAMES 'cone mode sparse-checkout completes directory names with backslashes and tabs' '
# reset sparse-checkout
git -C sparse-checkout sparse-checkout disable &&
(
cd sparse-checkout &&
mkdir "directory\with\backslashes" &&
mkdir "$(printf "directory\twith\ttabs")" &&
>"directory\with\backslashes/randomfile" &&
>"$(printf "directory\twith\ttabs")/randomfile" &&
git add . &&
git commit -m "Add directory with backslashes and directory with tabs" &&
git sparse-checkout set --cone "directory\with\backslashes" \
"$(printf "directory\twith\ttabs")" &&
test_completion "git sparse-checkout add dir" <<-\EOF &&
directory\with\backslashes/
directory with tabs/
EOF
rm -rf "directory\with\backslashes" &&
rm -rf "$(printf "directory\twith\ttabs")" &&
git add . &&
git commit -m "Remove directory with backslashes and directory with tabs"
)
'
test_expect_success 'non-cone mode sparse-checkout uses bash completion' '
# reset sparse-checkout repo to non-cone mode
git -C sparse-checkout sparse-checkout disable &&
git -C sparse-checkout sparse-checkout set --no-cone &&
(
cd sparse-checkout &&
# expected to be empty since we have not configured
# custom completion for non-cone mode
test_completion "git sparse-checkout set f" <<-\EOF
EOF
)
'
test_expect_success 'git sparse-checkout set --cone completes directory names' '
git -C sparse-checkout sparse-checkout disable &&
(
cd sparse-checkout &&
test_completion "git sparse-checkout set --cone f" <<-\EOF
folder1/
folder2/
folder3/
EOF
)
'
test_expect_success 'git switch - with -d, complete all references' '
test_completion "git switch -d " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with -d, complete only references' '
test_completion "git checkout -d " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with --track, complete only remote branches' '
test_completion "git switch --track " <<-\EOF
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with --track, complete only remote branches' '
test_completion "git checkout --track " <<-\EOF
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with --no-track, complete only local branch names' '
test_completion "git switch --no-track " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - with --no-track, complete only local references' '
test_completion "git checkout --no-track " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with -c, complete all references' '
test_completion "git switch -c new-branch " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with -C, complete all references' '
test_completion "git switch -C new-branch " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with -c and --track, complete all references' '
test_completion "git switch -c new-branch --track " <<-EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with -C and --track, complete all references' '
test_completion "git switch -C new-branch --track " <<-EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with -c and --no-track, complete all references' '
test_completion "git switch -c new-branch --no-track " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - with -C and --no-track, complete all references' '
test_completion "git switch -C new-branch --no-track " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with -b, complete all references' '
test_completion "git checkout -b new-branch " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with -B, complete all references' '
test_completion "git checkout -B new-branch " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with -b and --track, complete all references' '
test_completion "git checkout -b new-branch --track " <<-EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with -B and --track, complete all references' '
test_completion "git checkout -B new-branch --track " <<-EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with -b and --no-track, complete all references' '
test_completion "git checkout -b new-branch --no-track " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git checkout - with -B and --no-track, complete all references' '
test_completion "git checkout -B new-branch --no-track " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'git switch - for -c, complete local branches and unique remote branches' '
test_completion "git switch -c " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
EOF
'
test_expect_success 'git switch - for -C, complete local branches and unique remote branches' '
test_completion "git switch -C " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
EOF
'
test_expect_success 'git switch - for -c with --no-guess, complete local branches only' '
test_completion "git switch --no-guess -c " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git switch - for -C with --no-guess, complete local branches only' '
test_completion "git switch --no-guess -C " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git switch - for -c with --no-track, complete local branches only' '
test_completion "git switch --no-track -c " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git switch - for -C with --no-track, complete local branches only' '
test_completion "git switch --no-track -C " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - for -b, complete local branches and unique remote branches' '
test_completion "git checkout -b " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - for -B, complete local branches and unique remote branches' '
test_completion "git checkout -B " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - for -b with --no-guess, complete local branches only' '
test_completion "git checkout --no-guess -b " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - for -B with --no-guess, complete local branches only' '
test_completion "git checkout --no-guess -B " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - for -b with --no-track, complete local branches only' '
test_completion "git checkout --no-track -b " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - for -B with --no-track, complete local branches only' '
test_completion "git checkout --no-track -B " <<-\EOF
main Z
matching-branch Z
EOF
'
test_expect_success 'git switch - with --orphan completes local branch names and unique remote branch names' '
test_completion "git switch --orphan " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
EOF
'
test_expect_success 'git switch - --orphan with branch already provided completes nothing else' '
test_completion "git switch --orphan main " <<-\EOF
EOF
'
test_expect_success 'git checkout - with --orphan completes local branch names and unique remote branch names' '
test_completion "git checkout --orphan " <<-\EOF
branch-in-other Z
main Z
main-in-other Z
matching-branch Z
EOF
'
test_expect_success 'git checkout - --orphan with branch already provided completes local refs for a start-point' '
test_completion "git checkout --orphan main " <<-\EOF
HEAD Z
main Z
matching-branch Z
matching-tag Z
other/branch-in-other Z
other/main-in-other Z
EOF
'
test_expect_success 'teardown after ref completion' '
git branch -d matching-branch &&
git tag -d matching-tag &&
git remote remove other
'
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
test_path_completion ()
{
tests: send "bug in the test script" errors to the script's stderr Some of the functions in our test library check that they were invoked properly with conditions like this: test "$#" = 2 || error "bug in the test script: not 2 parameters to test-expect-success" If this particular condition is triggered, then 'error' will abort the whole test script with a bold red error message [1] right away. However, under certain circumstances the test script will be aborted completely silently, namely if: - a similar condition in a test helper function like 'test_line_count' is triggered, - which is invoked from the test script's "main" shell [2], - and the test script is run manually (i.e. './t1234-foo.sh' as opposed to 'make t1234-foo.sh' or 'make test') [3] - and without the '--verbose' option, because the error message is printed from within 'test_eval_', where standard output is redirected either to /dev/null or to a log file. The only indication that something is wrong is that not all tests in the script are executed and at the end of the test script's output there is no "# passed all N tests" message, which are subtle and can easily go unnoticed, as I had to experience myself. Send these "bug in the test script" error messages directly to the test scripts standard error and thus to the terminal, so those bugs will be much harder to overlook. Instead of updating all ~20 such 'error' calls with a redirection, let's add a BUG() function to 'test-lib.sh', wrapping an 'error' call with the proper redirection and also including the common prefix of those error messages, and convert all those call sites [4] to use this new BUG() function instead. [1] That particular error message from 'test_expect_success' is printed in color only when running with or without '--verbose'; with '--tee' or '--verbose-log' the error is printed without color, but it is printed to the terminal nonetheless. [2] If such a condition is triggered in a subshell of a test, then 'error' won't be able to abort the whole test script, but only the subshell, which in turn causes the test to fail in the usual way, indicating loudly and clearly that something is wrong. [3] Well, 'error' aborts the test script the same way when run manually or by 'make' or 'prove', but both 'make' and 'prove' pay attention to the test script's exit status, and even a silently aborted test script would then trigger those tools' usual noticable error messages. [4] Strictly speaking, not all those 'error' calls need that redirection to send their output to the terminal, see e.g. 'test_expect_success' in the opening example, but I think it's better to be consistent. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 14:13:26 +01:00
test $# = 2 || BUG "not 2 parameters to test_path_completion"
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
local cur="$1" expected="$2"
echo "$expected" >expected &&
(
# In the following tests calling this function we only
# care about how __git_complete_index_file() deals with
# unusual characters in path names. By requesting only
# untracked files we do not have to bother adding any
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
# paths to the index in those tests.
__git_complete_index_file --others &&
print_comp
) &&
test_cmp expected out
}
test_expect_success 'setup for path completion tests' '
mkdir simple-dir \
"spaces in dir" \
árvíztűrő &&
touch simple-dir/simple-file \
"spaces in dir/spaces in file" \
"árvíztűrő/Сайн яваарай" &&
if test_have_prereq !MINGW &&
mkdir BS\\dir \
'$'separators\034in\035dir'' &&
touch BS\\dir/DQ\"file \
'$'separators\034in\035dir/sep\036in\037file''
then
test_set_prereq FUNNIERNAMES
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
else
rm -rf BS\\dir '$'separators\034in\035dir''
fi
'
test_expect_success '__git_complete_index_file - simple' '
test_path_completion simple simple-dir && # Bash is supposed to
# add the trailing /.
test_path_completion simple-dir/simple simple-dir/simple-file
'
test_expect_success \
'__git_complete_index_file - escaped characters on cmdline' '
test_path_completion spac "spaces in dir" && # Bash will turn this
# into "spaces\ in\ dir"
test_path_completion "spaces\\ i" \
"spaces in dir" &&
test_path_completion "spaces\\ in\\ dir/s" \
"spaces in dir/spaces in file" &&
test_path_completion "spaces\\ in\\ dir/spaces\\ i" \
"spaces in dir/spaces in file"
'
test_expect_success \
'__git_complete_index_file - quoted characters on cmdline' '
# Testing with an opening but without a corresponding closing
# double quote is important.
test_path_completion \"spac "spaces in dir" &&
test_path_completion "\"spaces i" \
"spaces in dir" &&
test_path_completion "\"spaces in dir/s" \
"spaces in dir/spaces in file" &&
test_path_completion "\"spaces in dir/spaces i" \
"spaces in dir/spaces in file"
'
test_expect_success '__git_complete_index_file - UTF-8 in ls-files output' '
test_path_completion á árvíztűrő &&
test_path_completion árvíztűrő/С "árvíztűrő/Сайн яваарай"
'
test_expect_success FUNNIERNAMES \
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
'__git_complete_index_file - C-style escapes in ls-files output' '
test_path_completion BS \
BS\\dir &&
test_path_completion BS\\\\d \
BS\\dir &&
test_path_completion BS\\\\dir/DQ \
BS\\dir/DQ\"file &&
test_path_completion BS\\\\dir/DQ\\\"f \
BS\\dir/DQ\"file
'
test_expect_success FUNNIERNAMES \
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
'__git_complete_index_file - \nnn-escaped characters in ls-files output' '
test_path_completion sep '$'separators\034in\035dir'' &&
test_path_completion '$'separators\034i'' \
'$'separators\034in\035dir'' &&
test_path_completion '$'separators\034in\035dir/sep'' \
'$'separators\034in\035dir/sep\036in\037file'' &&
test_path_completion '$'separators\034in\035dir/sep\036i'' \
'$'separators\034in\035dir/sep\036in\037file''
'
test_expect_success FUNNYNAMES \
'__git_complete_index_file - removing repeated quoted path components' '
test_when_finished rm -r repeated-quoted &&
mkdir repeated-quoted && # A directory whose name in itself
# would not be quoted ...
>repeated-quoted/0-file &&
>repeated-quoted/1\"file && # ... but here the file makes the
# dirname quoted ...
>repeated-quoted/2-file &&
>repeated-quoted/3\"file && # ... and here, too.
# Still, we shold only list the directory name only once.
test_path_completion repeated repeated-quoted
'
test_expect_success 'teardown after path completion tests' '
rm -rf simple-dir "spaces in dir" árvíztűrő \
BS\\dir '$'separators\034in\035dir''
'
test_expect_success '__git_find_on_cmdline - single match' '
echo list >expect &&
(
words=(git command --opt list) &&
cword=${#words[@]} &&
__git_cmd_idx=1 &&
__git_find_on_cmdline "add list remove" >actual
) &&
test_cmp expect actual
'
test_expect_success '__git_find_on_cmdline - multiple matches' '
echo remove >expect &&
(
words=(git command -o --opt remove list add) &&
cword=${#words[@]} &&
__git_cmd_idx=1 &&
__git_find_on_cmdline "add list remove" >actual
) &&
test_cmp expect actual
'
test_expect_success '__git_find_on_cmdline - no match' '
(
words=(git command --opt branch) &&
cword=${#words[@]} &&
__git_cmd_idx=1 &&
__git_find_on_cmdline "add list remove" >actual
) &&
test_must_be_empty actual
'
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
test_expect_success '__git_find_on_cmdline - single match with index' '
echo "3 list" >expect &&
(
words=(git command --opt list) &&
cword=${#words[@]} &&
__git_cmd_idx=1 &&
__git_find_on_cmdline --show-idx "add list remove" >actual
) &&
test_cmp expect actual
'
test_expect_success '__git_find_on_cmdline - multiple matches with index' '
echo "4 remove" >expect &&
(
words=(git command -o --opt remove list add) &&
cword=${#words[@]} &&
__git_cmd_idx=1 &&
__git_find_on_cmdline --show-idx "add list remove" >actual
) &&
test_cmp expect actual
'
test_expect_success '__git_find_on_cmdline - no match with index' '
(
words=(git command --opt branch) &&
cword=${#words[@]} &&
__git_cmd_idx=1 &&
__git_find_on_cmdline --show-idx "add list remove" >actual
) &&
test_must_be_empty actual
'
t9902-completion: exercise __git_complete_index_file() directly The tests added in 2f271cd9cf (t9902-completion: add tests demonstrating issues with quoted pathnames, 2018-05-08) and in 2ab6eab4fe (completion: improve handling quoted paths in 'git ls-files's output, 2018-03-28) have a few shortcomings: - All these tests use the 'test_completion' helper function, thus they are exercising the whole completion machinery, although they are only interested in how git-aware path completion, specifically the __git_complete_index_file() function deals with unusual characters in pathnames and on the command line. - These tests can't satisfactorily test the case of pathnames containing spaces, because 'test_completion' gets the words on the command line as a single argument and it uses space as word separator. - Some of the tests are protected by different FUNNYNAMES_* prereqs depending on whether they put backslashes and double quotes or separator characters (FS, GS, RS, US) in pathnames, although a filesystem not allowing one likely doesn't allow the others either. - One of the tests operates on paths containing '|' and '&' characters without being protected by a FUNNYNAMES prereq, but some filesystems (notably on Windows) don't allow these characters in pathnames, either. Replace these tests with basically equivalent, more focused tests that call __git_complete_index_file() directly. Since this function only looks at the current word to be completed, i.e. the $cur variable, we can easily include pathnames containing spaces in the tests, so use such pathnames instead of pathnames containing '|' and '&'. Finally, use only a single FUNNYNAMES prereq for all kinds of special characters. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18 16:17:51 +02:00
test_expect_success '__git_find_on_cmdline - ignores matches before command with index' '
echo "6 remove" >expect &&
(
words=(git -C remove command -o --opt remove list add) &&
cword=${#words[@]} &&
__git_cmd_idx=3 &&
__git_find_on_cmdline --show-idx "add list remove" >actual
) &&
test_cmp expect actual
'
test_expect_success '__git_get_config_variables' '
cat >expect <<-EOF &&
name-1
name-2
EOF
test_config interesting.name-1 good &&
test_config interesting.name-2 good &&
test_config subsection.interesting.name-3 bad &&
__git_get_config_variables interesting >actual &&
test_cmp expect actual
'
test_expect_success '__git_pretty_aliases' '
cat >expect <<-EOF &&
author
hash
EOF
test_config pretty.author "%an %ae" &&
test_config pretty.hash %H &&
__git_pretty_aliases >actual &&
test_cmp expect actual
'
test_expect_success 'basic' '
run_completion "git " &&
# built-in
grep -q "^add \$" out &&
# script
grep -q "^rebase \$" out &&
# plumbing
! grep -q "^ls-files \$" out &&
run_completion "git r" &&
! grep -q -v "^r" out
'
test_expect_success 'double dash "git" itself' '
test_completion "git --" <<-\EOF
--paginate Z
--no-pager Z
--git-dir=
--bare Z
--version Z
--exec-path Z
--exec-path=
--html-path Z
--man-path Z
--info-path Z
--work-tree=
--namespace=
--no-replace-objects Z
--help Z
EOF
'
test_expect_success 'double dash "git checkout"' '
test_completion "git checkout --" <<-\EOF
--quiet Z
--detach Z
--track Z
--orphan=Z
--ours Z
--theirs Z
--merge Z
--conflict=Z
--patch Z
--ignore-skip-worktree-bits Z
--ignore-other-worktrees Z
--recurse-submodules Z
--progress Z
checkout: disambiguate dwim tracking branches and local files When checkout dwim is added in [1], it is restricted to only dwim when certain conditions are met and fall back to default checkout behavior otherwise. It turns out falling back could be confusing. One of the conditions to turn git checkout frotz to git checkout -b frotz origin/frotz is that frotz must not exist as a file. But when the user comes to expect "git checkout frotz" to create the branch "frotz" and there happens to be a file named "frotz", git's silently reverting "frotz" file content is not helping. This is reported in Git mailing list [2] and even used as an example of "Git is bad" elsewhere [3]. We normally try to do the right thing, but when there are multiple "right things" to do, it's best to leave it to the user to decide. Check this case, ask the user to to disambiguate: - "git checkout -- foo" will check out path "foo" - "git checkout foo --" will dwim and create branch "foo" [4] For users who do not want dwim, use --no-guess. It's useless in this particular case because "git checkout --no-guess foo --" will just fail. But it could be used by scripts. [1] 70c9ac2f19 (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz" - 2009-10-18) [2] https://public-inbox.org/git/CACsJy8B2TVr1g+k+eSQ=pBEO3WN4_LtgLo9gpur8X7Z9GOFL_A@mail.gmail.com/ [3] https://news.ycombinator.com/item?id=18230655 [4] a047fafc78 (checkout: allow dwim for branch creation for "git checkout $branch --" - 2013-10-18) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13 18:52:26 +01:00
--guess Z
--no-guess Z
completion: collapse extra --no-.. options The commands that make use of --git-completion-helper feature could now produce a lot of --no-xxx options that a command can take. This in many case could nearly double the amount of completable options, using more screen estate and also harder to search for the wanted option. This patch attempts to mitigate that by collapsing extra --no- options, the ones that are added by --git-completion-helper and not in original struct option arrays. The "--no-..." option will be displayed in this case to hint about more options, e.g. > ~/w/git $ git clone -- --bare --origin= --branch= --progress --checkout --quiet --config= --recurse-submodules --depth= --reference= --dissociate --reference-if-able= --filter= --separate-git-dir= --hardlinks --shallow-exclude= --ipv4 --shallow-since= --ipv6 --shallow-submodules --jobs= --shared --local --single-branch --mirror --tags --no-... --template= --no-checkout --upload-pack= --no-hardlinks --verbose --no-tags and when you complete it with --no-<tab>, all negative options will be presented: > ~/w/git $ git clone --no- --no-bare --no-quiet --no-branch --no-recurse-submodules --no-checkout --no-reference --no-config --no-reference-if-able --no-depth --no-separate-git-dir --no-dissociate --no-shallow-exclude --no-filter --no-shallow-since --no-hardlinks --no-shallow-submodules --no-ipv4 --no-shared --no-ipv6 --no-single-branch --no-jobs --no-tags --no-local --no-template --no-mirror --no-upload-pack --no-origin --no-verbose --no-progress Corner case: to make sure that people will never accidentally complete the fake option "--no-..." there must be one real --no- in the first complete listing even if it's not from the original struct option. PS. This could could be made simpler with ";&" to fall through from "--no-*" block and share the code but ";&" is not available on bash-3 (i.e. Mac) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-06 11:41:39 +02:00
--no-... Z
--overlay Z
--pathspec-file-nul Z
--pathspec-from-file=Z
EOF
'
test_expect_success 'general options' '
test_completion "git --ver" "--version " &&
test_completion "git --hel" "--help " &&
test_completion "git --exe" <<-\EOF &&
--exec-path Z
--exec-path=
EOF
test_completion "git --htm" "--html-path " &&
test_completion "git --pag" "--paginate " &&
test_completion "git --no-p" "--no-pager " &&
test_completion "git --git" "--git-dir=" &&
test_completion "git --wor" "--work-tree=" &&
test_completion "git --nam" "--namespace=" &&
test_completion "git --bar" "--bare " &&
test_completion "git --inf" "--info-path " &&
test_completion "git --no-r" "--no-replace-objects "
'
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 21:44:20 +02:00
test_expect_success 'general options plus command' '
test_completion "git --version check" "checkout " &&
test_completion "git --paginate check" "checkout " &&
test_completion "git --git-dir=foo check" "checkout " &&
test_completion "git --bare check" "checkout " &&
test_completion "git --exec-path=foo check" "checkout " &&
test_completion "git --html-path check" "checkout " &&
test_completion "git --no-pager check" "checkout " &&
test_completion "git --work-tree=foo check" "checkout " &&
test_completion "git --namespace=foo check" "checkout " &&
test_completion "git --paginate check" "checkout " &&
test_completion "git --info-path check" "checkout " &&
completion: fix completion after 'git -C <path>' The main completion function finds the name of the git command by iterating through all the words on the command line in search for the first non-option-looking word. As it is not aware of 'git -C's mandatory path argument, if the '-C <path>' option is present, 'path' will be the first such word and it will be mistaken for a git command. This breaks completion in various ways: - If 'path' happens to match one of the commands supported by the completion script, then options of that command will be offered. - If 'path' doesn't match a supported command and doesn't contain any characters not allowed in Bash identifier names, then the completion script does basically nothing and Bash in turn falls back to filename completion for all subsequent words. - Otherwise, if 'path' does contain such an unallowed character, then it leads to a more or less ugly error message in the middle of the command line. The standard '/' directory separator is such a character, and it happens to trigger one of the uglier errors: $ git -C some/path <TAB>sh.exe": declare: `_git_some/path': not a valid identifier error: invalid key: alias.some/path Fix this by skipping 'git -C's mandatory path argument while iterating over the words on the command line. Extend the relevant test with this case and, while at it, with cases that needed similar treatment in the past ('--git-dir', '-c', '--work-tree' and '--namespace'). Additionally, silence the standard error of the 'declare' builtins looking for the completion function associated with the git command and of the 'git config' query for the aliased command. So if git ever learns a new option with a mandatory argument in the future, then, though the completion script will again misbehave, at least the command line will not be utterly disrupted by those error messages. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:22 +01:00
test_completion "git --no-replace-objects check" "checkout " &&
test_completion "git --git-dir some/path check" "checkout " &&
test_completion "git -c conf.var=value check" "checkout " &&
test_completion "git -C some/path check" "checkout " &&
test_completion "git --work-tree some/path check" "checkout " &&
test_completion "git --namespace name/space check" "checkout "
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 21:44:20 +02:00
'
test_expect_success 'git --help completion' '
test_completion "git --help ad" "add " &&
test_completion "git --help core" "core-tutorial "
'
test_expect_success 'completion.commands removes multiple commands' '
test_config completion.commands "-cherry -mergetool" &&
git --list-cmds=list-mainporcelain,list-complete,config >out &&
! grep -E "^(cherry|mergetool)$" out
'
test_expect_success 'setup for integration tests' '
echo content >file1 &&
echo more >file2 &&
git add file1 file2 &&
git commit -m one &&
git branch mybranch &&
git tag mytag
'
test_expect_success 'checkout completes ref names' '
test_completion "git checkout m" <<-\EOF
main Z
mybranch Z
mytag Z
EOF
'
completion: respect 'git -C <path>' 'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 03:48:24 +01:00
test_expect_success 'git -C <path> checkout uses the right repo' '
test_completion "git -C subdir -C subsubdir -C .. -C ../otherrepo checkout b" <<-\EOF
branch-in-other Z
EOF
'
test_expect_success 'show completes all refs' '
test_completion "git show m" <<-\EOF
main Z
mybranch Z
mytag Z
EOF
'
test_expect_success '<ref>: completes paths' '
test_completion "git show mytag:f" <<-\EOF
completion: treat results of git ls-tree as file paths Let's say there are files named 'foo bar.txt', and 'abc def/test.txt' in repository. When following commands trigger a completion: git show HEAD:fo<Tab> git show HEAD:ab<Tab> The completion results in bash/zsh: git show HEAD:foo bar.txt git show HEAD:abc def/ Where the both of them have an unescaped space in paths, so they'll be misread by git. All entries of git ls-tree either a filename or a directory, so __gitcomp_file() is proper rather than __gitcomp_nl(). Note the commit f12785a3, which handles quoted paths properly. Like this case, we should dequote $cur_ for ?*:* case. For example, let's say there is untracked directory 'abc deg', then trigger a completion: git show HEAD:abc\ de<Tab> git show HEAD:'abc de<Tab> git show HEAD:"abc de<Tab> should uniquely complete 'abc def', but bash completes 'abc def' and 'abc deg' instead. In zsh, triggering a completion: git show HEAD:abc\ def/<Tab> should complete 'test.txt', but nothing comes. The both problems will be resolved by dequoting paths. __git_complete_revlist_file() passes arguments to __gitcomp_nl() where the first one is a list something like: abc def/Z foo bar.txt Z where Z is the mark of the EOL. - The trailing space of blob in __git ls-tree | sed. It makes the completion results become: git show HEAD:foo\ bar.txt\ <CURSOR> So git will try to find a file named 'foo bar.txt ' instead. - The trailing slash of tree in __git ls-tree | sed. It makes the completion results on zsh become: git show HEAD:abc\ def/ <CURSOR> So that the last space on command like should be removed on zsh to complete filenames under 'abc def/'. Signed-off-by: Chayoung You <yousbe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-01 15:05:09 +01:00
file1Z
file2Z
EOF
'
test_expect_success 'complete tree filename with spaces' '
echo content >"name with spaces" &&
git add "name with spaces" &&
git commit -m spaces &&
test_completion "git show HEAD:nam" <<-\EOF
completion: treat results of git ls-tree as file paths Let's say there are files named 'foo bar.txt', and 'abc def/test.txt' in repository. When following commands trigger a completion: git show HEAD:fo<Tab> git show HEAD:ab<Tab> The completion results in bash/zsh: git show HEAD:foo bar.txt git show HEAD:abc def/ Where the both of them have an unescaped space in paths, so they'll be misread by git. All entries of git ls-tree either a filename or a directory, so __gitcomp_file() is proper rather than __gitcomp_nl(). Note the commit f12785a3, which handles quoted paths properly. Like this case, we should dequote $cur_ for ?*:* case. For example, let's say there is untracked directory 'abc deg', then trigger a completion: git show HEAD:abc\ de<Tab> git show HEAD:'abc de<Tab> git show HEAD:"abc de<Tab> should uniquely complete 'abc def', but bash completes 'abc def' and 'abc deg' instead. In zsh, triggering a completion: git show HEAD:abc\ def/<Tab> should complete 'test.txt', but nothing comes. The both problems will be resolved by dequoting paths. __git_complete_revlist_file() passes arguments to __gitcomp_nl() where the first one is a list something like: abc def/Z foo bar.txt Z where Z is the mark of the EOL. - The trailing space of blob in __git ls-tree | sed. It makes the completion results become: git show HEAD:foo\ bar.txt\ <CURSOR> So git will try to find a file named 'foo bar.txt ' instead. - The trailing slash of tree in __git ls-tree | sed. It makes the completion results on zsh become: git show HEAD:abc\ def/ <CURSOR> So that the last space on command like should be removed on zsh to complete filenames under 'abc def/'. Signed-off-by: Chayoung You <yousbe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-01 15:05:09 +01:00
name with spacesZ
EOF
'
test_expect_success 'complete tree filename with metacharacters' '
echo content >"name with \${meta}" &&
git add "name with \${meta}" &&
git commit -m meta &&
test_completion "git show HEAD:nam" <<-\EOF
completion: treat results of git ls-tree as file paths Let's say there are files named 'foo bar.txt', and 'abc def/test.txt' in repository. When following commands trigger a completion: git show HEAD:fo<Tab> git show HEAD:ab<Tab> The completion results in bash/zsh: git show HEAD:foo bar.txt git show HEAD:abc def/ Where the both of them have an unescaped space in paths, so they'll be misread by git. All entries of git ls-tree either a filename or a directory, so __gitcomp_file() is proper rather than __gitcomp_nl(). Note the commit f12785a3, which handles quoted paths properly. Like this case, we should dequote $cur_ for ?*:* case. For example, let's say there is untracked directory 'abc deg', then trigger a completion: git show HEAD:abc\ de<Tab> git show HEAD:'abc de<Tab> git show HEAD:"abc de<Tab> should uniquely complete 'abc def', but bash completes 'abc def' and 'abc deg' instead. In zsh, triggering a completion: git show HEAD:abc\ def/<Tab> should complete 'test.txt', but nothing comes. The both problems will be resolved by dequoting paths. __git_complete_revlist_file() passes arguments to __gitcomp_nl() where the first one is a list something like: abc def/Z foo bar.txt Z where Z is the mark of the EOL. - The trailing space of blob in __git ls-tree | sed. It makes the completion results become: git show HEAD:foo\ bar.txt\ <CURSOR> So git will try to find a file named 'foo bar.txt ' instead. - The trailing slash of tree in __git ls-tree | sed. It makes the completion results on zsh become: git show HEAD:abc\ def/ <CURSOR> So that the last space on command like should be removed on zsh to complete filenames under 'abc def/'. Signed-off-by: Chayoung You <yousbe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-01 15:05:09 +01:00
name with ${meta}Z
name with spacesZ
EOF
'
test_expect_success PERL 'send-email' '
test_completion "git send-email --cov" <<-\EOF &&
--cover-from-description=Z
--cover-letter Z
EOF
test_completion "git send-email --val" <<-\EOF &&
--validate Z
EOF
test_completion "git send-email ma" "main "
'
test_expect_success 'complete files' '
git init tmp && cd tmp &&
test_when_finished "cd .. && rm -rf tmp" &&
echo "expected" > .gitignore &&
echo "out" >> .gitignore &&
t9902-completion: ignore COMPREPLY element order in some tests The order or possible completion words in the COMPREPLY array doesn't actually matter, as long as all the right words are in there, because Bash will sort them anyway. Yet, our tests looking at the elements of COMPREPLY always expect them to be in a specific order. Now, this hasn't been an issue before, but the next patch is about to optimize a bit more our git-aware path completion, and as a harmless side effect the order of elements in COMPREPLY will change. Worse, the order will be downright undefined, because after the next patch path components will come directly from iterating through an associative array in 'awk', and the order of iteration over the elements in those arrays is undefined, and indeed different 'awk' implementations produce different order. Consequently, we can't get away with simply adjusting the expected results in the affected tests. Modify the 'test_completion' helper function to sort both the expected and the actual results, i.e. the elements in COMPREPLY, before comparing them, so the tests using this helper function will work regardless of the order of elements. Note that this change still leaves a bunch of tests depending on the order of elements in COMPREPLY, tests that focus on a specific helper function and therefore don't use the 'test_completion' helper. I would rather deal with those later, when (if ever) the need actually arises, than create unnecessary code churn now. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-17 00:41:12 +02:00
echo "out_sorted" >> .gitignore &&
git add .gitignore &&
test_completion "git commit " ".gitignore" &&
git commit -m ignore &&
touch new &&
test_completion "git add " "new" &&
git add new &&
git commit -a -m new &&
test_completion "git add " "" &&
git mv new modified &&
echo modify > modified &&
test_completion "git add " "modified" &&
completion: fix 'git add' on paths under an untracked directory As reported on the git mailing list, since git-2.25, git add untracked-dir/ has been tab completing to git add untracked-dir/./ The cause for this was that with commit b9670c1f5e (dir: fix checks on common prefix directory, 2019-12-19), git ls-files -o --directory untracked-dir/ (or the equivalent `git -C untracked-dir ls-files -o --directory`) began reporting untracked-dir/ instead of listing paths underneath that directory. It may also be worth noting that the real command in question was git -C untracked-dir ls-files -o --directory '*' which is equivalent to git ls-files -o --directory 'untracked-dir/*' which behaves the same for the purposes of this issue (the '*' can match the empty string), but becomes relevant for the proposed fix. At first, based on the report, I decided to try to view this as a regression and tried to find a way to recover the old behavior without breaking other stuff, or at least breaking as little as possible. However, in the end, I couldn't figure out a way to do it that wouldn't just cause lots more problems than it solved. The old behavior was a bug: * Although older git would avoid cleaning anything with `git clean -f .git`, it would wipe out everything under that direcotry with `git clean -f .git/`. Despite the difference in command used, this is relevant because the exact same change that fixed clean changed the behavior of ls-files. * Older git would report different results based solely on presence or absence of a trailing slash for $SUBDIR in the command `git ls-files -o --directory $SUBDIR`. * Older git violated the documented behavior of not recursing into directories that matched the pathspec when --directory was specified. * And, after all, commit b9670c1f5e (dir: fix checks on common prefix directory, 2019-12-19) didn't overlook this issue; it explicitly stated that the behavior of the command was being changed to bring it inline with the docs. (Also, if it helps, despite that commit being merged during the 2.25 series, this bug was not reported during the 2.25 cycle, nor even during most of the 2.26 cycle -- it was reported a day before 2.26 was released. So the impact of the change is at least somewhat small.) Instead of relying on a bug of ls-files in reporting the wrong content, change the invocation of ls-files used by git-completion to make it grab paths one depth deeper. Do this by changing '$DIR/*' (match $DIR/ plus 0 or more characters) into '$DIR/?*' (match $DIR/ plus 1 or more characters). Note that the '?' character should not be added when trying to complete a filename (e.g. 'git ls-files -o --directory "merge.c?*"' would not correctly return "merge.c" when such a file exists), so we have to make sure to add the '?' character only in cases where the path specified so far is a directory. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-01 06:17:46 +02:00
mkdir -p some/deep &&
touch some/deep/path &&
test_completion "git add some/" "some/deep" &&
git clean -f some &&
touch untracked &&
: TODO .gitignore should not be here &&
test_completion "git rm " <<-\EOF &&
.gitignore
modified
EOF
test_completion "git clean " "untracked" &&
: TODO .gitignore should not be here &&
test_completion "git mv " <<-\EOF &&
.gitignore
modified
EOF
mkdir dir &&
touch dir/file-in-dir &&
git add dir/file-in-dir &&
git commit -m dir &&
mkdir untracked-dir &&
: TODO .gitignore should not be here &&
test_completion "git mv modified " <<-\EOF &&
.gitignore
dir
modified
untracked
untracked-dir
EOF
test_completion "git commit " "modified" &&
: TODO .gitignore should not be here &&
test_completion "git ls-files " <<-\EOF &&
.gitignore
dir
modified
EOF
touch momified &&
test_completion "git add mom" "momified"
'
test_expect_success "simple alias" '
test_config alias.co checkout &&
test_completion "git co m" <<-\EOF
main Z
mybranch Z
mytag Z
EOF
'
test_expect_success "recursive alias" '
test_config alias.co checkout &&
test_config alias.cod "co --detached" &&
test_completion "git cod m" <<-\EOF
main Z
mybranch Z
mytag Z
EOF
'
test_expect_success "completion uses <cmd> completion for alias: !sh -c 'git <cmd> ...'" '
test_config alias.co "!sh -c '"'"'git checkout ...'"'"'" &&
test_completion "git co m" <<-\EOF
main Z
mybranch Z
mytag Z
EOF
'
test_expect_success 'completion uses <cmd> completion for alias: !f () { VAR=val git <cmd> ... }' '
test_config alias.co "!f () { VAR=val git checkout ... ; } f" &&
test_completion "git co m" <<-\EOF
main Z
mybranch Z
mytag Z
EOF
'
test_expect_success 'completion used <cmd> completion for alias: !f() { : git <cmd> ; ... }' '
test_config alias.co "!f() { : git checkout ; if ... } f" &&
test_completion "git co m" <<-\EOF
main Z
mybranch Z
mytag Z
EOF
'
test_expect_success 'completion without explicit _git_xxx function' '
test_completion "git version --" <<-\EOF
--build-options Z
--no-build-options Z
EOF
'
test_expect_failure 'complete with tilde expansion' '
git init tmp && cd tmp &&
test_when_finished "cd .. && rm -rf tmp" &&
touch ~/tmp/file &&
test_completion "git add ~/tmp/" "~/tmp/file"
'
test_expect_success 'setup other remote for remote reference completion' '
git remote add other otherrepo &&
git fetch other
'
for flag in -d --delete
do
test_expect_success "__git_complete_remote_or_refspec - push $flag other" '
sed -e "s/Z$//" >expected <<-EOF &&
main-in-other Z
EOF
(
words=(git push '$flag' other ma) &&
cword=${#words[@]} cur=${words[cword-1]} &&
__git_cmd_idx=1 &&
__git_complete_remote_or_refspec &&
print_comp
) &&
test_cmp expected out
'
test_expect_failure "__git_complete_remote_or_refspec - push other $flag" '
sed -e "s/Z$//" >expected <<-EOF &&
main-in-other Z
EOF
(
words=(git push other '$flag' ma) &&
cword=${#words[@]} cur=${words[cword-1]} &&
__git_cmd_idx=1 &&
__git_complete_remote_or_refspec &&
print_comp
) &&
test_cmp expected out
'
done
completion: deduplicate configuration sections The number of configuration variables listed by the completion script grew quite when we started to auto-generate it from the documentation [1], so we now complete them in two steps: first we list only the section names, then the rest [2]. To get the section names we simply strip everything following the first dot in each variable name, resulting in a lot of repeated section names, because most sections contain more than one configuration variable. This is not a correctness issue in practice, because Bash's completion facilities remove all repetitions anyway, but these repetitions make testing a bit harder. Replace the small 'sed' script removing subsections and variable names with an 'awk' script that does the same, and in addition removes any repeated configuration sections as well (by first creating and filling an associative array indexed by all encountered configuration sections, and then iterating over this array and printing the indices, i.e. the unique section names). This change makes the failing 'git config - section' test in 't9902-completion.sh' pass. Note that this changes the order of section names in the output, and makes it downright undeterministic, but this is not an issue, because Bash sorts them before presenting them to the user, and our completion tests sort them as well before comparing with the expected output. Yeah, it would be simpler and shorter to just append '| sort -u' to that command, but that would incur the overhead of one more external process and pipeline stage every time a user completes configuration sections. [1] e17ca92637 (completion: drop the hard coded list of config vars, 2018-05-26) [2] f22f682695 (completion: complete general config vars in two steps, 2018-05-27) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13 14:26:45 +02:00
test_expect_success 'git config - section' '
test_completion "git config br" <<-\EOF
branch.Z
browser.Z
EOF
'
test_expect_success 'git config - variable name' '
test_completion "git config log.d" <<-\EOF
log.date Z
log.decorate Z
log.diffMerges Z
EOF
'
test_expect_success 'git config - value' '
test_completion "git config color.pager " <<-\EOF
false Z
true Z
EOF
'
test_expect_success 'git -c - section' '
test_completion "git -c br" <<-\EOF
branch.Z
browser.Z
EOF
'
test_expect_success 'git -c - variable name' '
test_completion "git -c log.d" <<-\EOF
log.date=Z
log.decorate=Z
log.diffMerges=Z
EOF
'
test_expect_success 'git -c - value' '
test_completion "git -c color.pager=" <<-\EOF
false Z
true Z
EOF
'
test_expect_success 'git clone --config= - section' '
test_completion "git clone --config=br" <<-\EOF
branch.Z
browser.Z
EOF
'
test_expect_success 'git clone --config= - variable name' '
test_completion "git clone --config=log.d" <<-\EOF
log.date=Z
log.decorate=Z
log.diffMerges=Z
EOF
'
test_expect_success 'git clone --config= - value' '
test_completion "git clone --config=color.pager=" <<-\EOF
false Z
true Z
EOF
'
test_expect_success 'options with value' '
test_completion "git merge -X diff-algorithm=" <<-\EOF
EOF
'
completion: clear cached --options when sourcing the completion script The established way to update the completion script in an already running shell is to simply source it again: this brings in any new --options and features, and clears caching variables. E.g. it clears the variables caching the list of (all|porcelain) git commands, so when they are later lazy-initialized again, then they will list and cache any newly installed commmands as well. Unfortunately, since d401f3debc (git-completion.bash: introduce __gitcomp_builtin, 2018-02-09) and subsequent patches this doesn't work for a lot of git commands' options. To eliminate a lot of hard-to-maintain hard-coded lists of options, those commits changed the completion script to use a bunch of programmatically created and lazy-initialized variables to cache the options of those builtin porcelain commands that use parse-options. These variables are not cleared upon sourcing the completion script, therefore they continue caching the old lists of options, even when some commands recently learned new options or when deprecated options were removed. Always 'unset' these variables caching the options of builtin commands when sourcing the completion script. Redirect 'unset's stderr to /dev/null, because ZSH's 'unset' complains if it's invoked without any arguments, i.e. no variables caching builtin's options are set. This can happen, if someone were to source the completion script twice without completing any --options in between. Bash stays silent in this case. Add tests to ensure that these variables are indeed cleared when the completion script is sourced; not just the variables caching options, but all other caching variables, i.e. the variables caching commands, porcelain commands and merge strategies as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-22 15:16:04 +01:00
test_expect_success 'sourcing the completion script clears cached commands' '
(
__git_compute_all_commands &&
verbose test -n "$__git_all_commands" &&
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
verbose test -z "$__git_all_commands"
)
completion: clear cached --options when sourcing the completion script The established way to update the completion script in an already running shell is to simply source it again: this brings in any new --options and features, and clears caching variables. E.g. it clears the variables caching the list of (all|porcelain) git commands, so when they are later lazy-initialized again, then they will list and cache any newly installed commmands as well. Unfortunately, since d401f3debc (git-completion.bash: introduce __gitcomp_builtin, 2018-02-09) and subsequent patches this doesn't work for a lot of git commands' options. To eliminate a lot of hard-to-maintain hard-coded lists of options, those commits changed the completion script to use a bunch of programmatically created and lazy-initialized variables to cache the options of those builtin porcelain commands that use parse-options. These variables are not cleared upon sourcing the completion script, therefore they continue caching the old lists of options, even when some commands recently learned new options or when deprecated options were removed. Always 'unset' these variables caching the options of builtin commands when sourcing the completion script. Redirect 'unset's stderr to /dev/null, because ZSH's 'unset' complains if it's invoked without any arguments, i.e. no variables caching builtin's options are set. This can happen, if someone were to source the completion script twice without completing any --options in between. Bash stays silent in this case. Add tests to ensure that these variables are indeed cleared when the completion script is sourced; not just the variables caching options, but all other caching variables, i.e. the variables caching commands, porcelain commands and merge strategies as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-22 15:16:04 +01:00
'
i18n: make GETTEXT_POISON a runtime option Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON test parameter to only be a GIT_TEST_GETTEXT_POISON=<non-empty?> runtime parameter, to be consistent with other parameters documented in "Running tests with special setups" in t/README. When I added GETTEXT_POISON in bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) I was concerned with ensuring that the _() function would get constant folded if NO_GETTEXT was defined, and likewise that GETTEXT_POISON would be compiled out unless it was defined. But as the benchmark in my [1] shows doing a one-off runtime getenv("GIT_TEST_[...]") is trivial, and since GETTEXT_POISON was originally added the GIT_TEST_* env variables have become the common idiom for turning on special test setups. So change GETTEXT_POISON to work the same way. Now the GETTEXT_POISON=YesPlease compile-time option is gone, and running the tests with GIT_TEST_GETTEXT_POISON=[YesPlease|] can be toggled on/off without recompiling. This allows for conditionally amending tests to test with/without poison, similar to what 859fdc0c3c ("commit-graph: define GIT_TEST_COMMIT_GRAPH", 2018-08-29) did for GIT_TEST_COMMIT_GRAPH. Do some of that, now we e.g. always run the t0205-gettext-poison.sh test. I did enough there to remove the GETTEXT_POISON prerequisite, but its inverse C_LOCALE_OUTPUT is still around, and surely some tests using it can be converted to e.g. always set GIT_TEST_GETTEXT_POISON=. Notes on the implementation: * We still compile a dedicated GETTEXT_POISON build in Travis CI. Perhaps this should be revisited and integrated into the "linux-gcc" build, see ae59a4e44f ("travis: run tests with GIT_TEST_SPLIT_INDEX", 2018-01-07) for prior art in that area. Then again maybe not, see [2]. * We now skip a test in t0000-basic.sh under GIT_TEST_GETTEXT_POISON=YesPlease that wasn't skipped before. This test relies on C locale output, but due to an edge case in how the previous implementation of GETTEXT_POISON worked (reading it from GIT-BUILD-OPTIONS) wasn't enabling poison correctly. Now it does, and needs to be skipped. * The getenv() function is not reentrant, so out of paranoia about code of the form: printf(_("%s"), getenv("some-env")); call use_gettext_poison() in our early setup in git_setup_gettext() so we populate the "poison_requested" variable in a codepath that's won't suffer from that race condition. * We error out in the Makefile if you're still saying GETTEXT_POISON=YesPlease to prompt users to change their invocation. * We should not print out poisoned messages during the test initialization itself to keep it more readable, so the test library hides the variable if set in $GIT_TEST_GETTEXT_POISON_ORIG during setup. See [3]. See also [4] for more on the motivation behind this patch, and the history of the GETTEXT_POISON facility. 1. https://public-inbox.org/git/871s8gd32p.fsf@evledraar.gmail.com/ 2. https://public-inbox.org/git/20181102163725.GY30222@szeder.dev/ 3. https://public-inbox.org/git/20181022202241.18629-2-szeder.dev@gmail.com/ 4. https://public-inbox.org/git/878t2pd6yu.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08 22:15:29 +01:00
test_expect_success 'sourcing the completion script clears cached merge strategies' '
(
__git_compute_merge_strategies &&
verbose test -n "$__git_merge_strategies" &&
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
verbose test -z "$__git_merge_strategies"
)
completion: clear cached --options when sourcing the completion script The established way to update the completion script in an already running shell is to simply source it again: this brings in any new --options and features, and clears caching variables. E.g. it clears the variables caching the list of (all|porcelain) git commands, so when they are later lazy-initialized again, then they will list and cache any newly installed commmands as well. Unfortunately, since d401f3debc (git-completion.bash: introduce __gitcomp_builtin, 2018-02-09) and subsequent patches this doesn't work for a lot of git commands' options. To eliminate a lot of hard-to-maintain hard-coded lists of options, those commits changed the completion script to use a bunch of programmatically created and lazy-initialized variables to cache the options of those builtin porcelain commands that use parse-options. These variables are not cleared upon sourcing the completion script, therefore they continue caching the old lists of options, even when some commands recently learned new options or when deprecated options were removed. Always 'unset' these variables caching the options of builtin commands when sourcing the completion script. Redirect 'unset's stderr to /dev/null, because ZSH's 'unset' complains if it's invoked without any arguments, i.e. no variables caching builtin's options are set. This can happen, if someone were to source the completion script twice without completing any --options in between. Bash stays silent in this case. Add tests to ensure that these variables are indeed cleared when the completion script is sourced; not just the variables caching options, but all other caching variables, i.e. the variables caching commands, porcelain commands and merge strategies as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-22 15:16:04 +01:00
'
test_expect_success 'sourcing the completion script clears cached --options' '
(
__gitcomp_builtin checkout &&
verbose test -n "$__gitcomp_builtin_checkout" &&
__gitcomp_builtin notes_edit &&
verbose test -n "$__gitcomp_builtin_notes_edit" &&
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
verbose test -z "$__gitcomp_builtin_checkout" &&
verbose test -z "$__gitcomp_builtin_notes_edit"
)
completion: clear cached --options when sourcing the completion script The established way to update the completion script in an already running shell is to simply source it again: this brings in any new --options and features, and clears caching variables. E.g. it clears the variables caching the list of (all|porcelain) git commands, so when they are later lazy-initialized again, then they will list and cache any newly installed commmands as well. Unfortunately, since d401f3debc (git-completion.bash: introduce __gitcomp_builtin, 2018-02-09) and subsequent patches this doesn't work for a lot of git commands' options. To eliminate a lot of hard-to-maintain hard-coded lists of options, those commits changed the completion script to use a bunch of programmatically created and lazy-initialized variables to cache the options of those builtin porcelain commands that use parse-options. These variables are not cleared upon sourcing the completion script, therefore they continue caching the old lists of options, even when some commands recently learned new options or when deprecated options were removed. Always 'unset' these variables caching the options of builtin commands when sourcing the completion script. Redirect 'unset's stderr to /dev/null, because ZSH's 'unset' complains if it's invoked without any arguments, i.e. no variables caching builtin's options are set. This can happen, if someone were to source the completion script twice without completing any --options in between. Bash stays silent in this case. Add tests to ensure that these variables are indeed cleared when the completion script is sourced; not just the variables caching options, but all other caching variables, i.e. the variables caching commands, porcelain commands and merge strategies as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-22 15:16:04 +01:00
'
parse-options: don't complete option aliases by default Since 'OPT_ALIAS' was created in 5c387428f1 (parse-options: don't emit "ambiguous option" for aliases, 2019-04-29), 'git clone --git-completion-helper', which is used by the Bash completion script to list options accepted by clone (via '__gitcomp_builtin'), lists both '--recurse-submodules' and its alias '--recursive', which was not the case before since '--recursive' had the PARSE_OPT_HIDDEN flag set, and options with this flag are skipped by 'parse-options.c::show_gitcomp', which implements 'git <cmd> --git-completion-helper'. This means that typing 'git clone --recurs<TAB>' will yield both '--recurse-submodules' and '--recursive', which is not ideal since both do the same thing, and so the completion should directly complete the canonical option. At the point where 'show_gitcomp' is called in 'parse_options_step', 'preprocess_options' was already called in 'parse_options', so any aliases are now copies of the original options with a modified help text indicating they are aliases. Helpfully, since 64cc539fd2 (parse-options: don't leak alias help messages, 2021-03-21) these copies have the PARSE_OPT_FROM_ALIAS flag set, so check that flag early in 'show_gitcomp' and do not print them, unless the user explicitely requested that *all* completion be shown (by setting 'GIT_COMPLETION_SHOW_ALL'). After all, if we want to encourage the use of '--recurse-submodules' over '--recursive', we'd better just suggest the former. The only other options alias is 'log' and friends' '--mailmap', which is an alias for '--use-mailmap', but the Bash completion helpers for these commands do not use '__gitcomp_builtin', and thus are unnaffected by this change. Test the new behaviour in t9902-completion.sh. As a side effect, this also tests the correct behaviour of GIT_COMPLETION_SHOW_ALL, which was not tested before. Note that since '__gitcomp_builtin' caches the options it shows, we need to re-source the completion script to clear that cache for the second test. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-16 03:55:43 +02:00
test_expect_success 'option aliases are not shown by default' '
test_completion "git clone --recurs" "--recurse-submodules "
'
test_expect_success 'option aliases are shown with GIT_COMPLETION_SHOW_ALL' '
(
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
GIT_COMPLETION_SHOW_ALL=1 && export GIT_COMPLETION_SHOW_ALL &&
test_completion "git clone --recurs" <<-\EOF
--recurse-submodules Z
--recursive Z
EOF
)
parse-options: don't complete option aliases by default Since 'OPT_ALIAS' was created in 5c387428f1 (parse-options: don't emit "ambiguous option" for aliases, 2019-04-29), 'git clone --git-completion-helper', which is used by the Bash completion script to list options accepted by clone (via '__gitcomp_builtin'), lists both '--recurse-submodules' and its alias '--recursive', which was not the case before since '--recursive' had the PARSE_OPT_HIDDEN flag set, and options with this flag are skipped by 'parse-options.c::show_gitcomp', which implements 'git <cmd> --git-completion-helper'. This means that typing 'git clone --recurs<TAB>' will yield both '--recurse-submodules' and '--recursive', which is not ideal since both do the same thing, and so the completion should directly complete the canonical option. At the point where 'show_gitcomp' is called in 'parse_options_step', 'preprocess_options' was already called in 'parse_options', so any aliases are now copies of the original options with a modified help text indicating they are aliases. Helpfully, since 64cc539fd2 (parse-options: don't leak alias help messages, 2021-03-21) these copies have the PARSE_OPT_FROM_ALIAS flag set, so check that flag early in 'show_gitcomp' and do not print them, unless the user explicitely requested that *all* completion be shown (by setting 'GIT_COMPLETION_SHOW_ALL'). After all, if we want to encourage the use of '--recurse-submodules' over '--recursive', we'd better just suggest the former. The only other options alias is 'log' and friends' '--mailmap', which is an alias for '--use-mailmap', but the Bash completion helpers for these commands do not use '__gitcomp_builtin', and thus are unnaffected by this change. Test the new behaviour in t9902-completion.sh. As a side effect, this also tests the correct behaviour of GIT_COMPLETION_SHOW_ALL, which was not tested before. Note that since '__gitcomp_builtin' caches the options it shows, we need to re-source the completion script to clear that cache for the second test. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-16 03:55:43 +02:00
'
test_expect_success 'plumbing commands are excluded without GIT_COMPLETION_SHOW_ALL_COMMANDS' '
(
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
sane_unset GIT_TESTING_PORCELAIN_COMMAND_LIST &&
# Just mainporcelain, not plumbing commands
run_completion "git c" &&
grep checkout out &&
! grep cat-file out
)
'
test_expect_success 'all commands are shown with GIT_COMPLETION_SHOW_ALL_COMMANDS (also main non-builtin)' '
(
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
GIT_COMPLETION_SHOW_ALL_COMMANDS=1 &&
export GIT_COMPLETION_SHOW_ALL_COMMANDS &&
sane_unset GIT_TESTING_PORCELAIN_COMMAND_LIST &&
# Both mainporcelain and plumbing commands
run_completion "git c" &&
grep checkout out &&
grep cat-file out &&
# Check "gitk", a "main" command, but not a built-in + more plumbing
run_completion "git g" &&
grep gitk out &&
grep get-tar-commit-id out
)
parse-options: don't complete option aliases by default Since 'OPT_ALIAS' was created in 5c387428f1 (parse-options: don't emit "ambiguous option" for aliases, 2019-04-29), 'git clone --git-completion-helper', which is used by the Bash completion script to list options accepted by clone (via '__gitcomp_builtin'), lists both '--recurse-submodules' and its alias '--recursive', which was not the case before since '--recursive' had the PARSE_OPT_HIDDEN flag set, and options with this flag are skipped by 'parse-options.c::show_gitcomp', which implements 'git <cmd> --git-completion-helper'. This means that typing 'git clone --recurs<TAB>' will yield both '--recurse-submodules' and '--recursive', which is not ideal since both do the same thing, and so the completion should directly complete the canonical option. At the point where 'show_gitcomp' is called in 'parse_options_step', 'preprocess_options' was already called in 'parse_options', so any aliases are now copies of the original options with a modified help text indicating they are aliases. Helpfully, since 64cc539fd2 (parse-options: don't leak alias help messages, 2021-03-21) these copies have the PARSE_OPT_FROM_ALIAS flag set, so check that flag early in 'show_gitcomp' and do not print them, unless the user explicitely requested that *all* completion be shown (by setting 'GIT_COMPLETION_SHOW_ALL'). After all, if we want to encourage the use of '--recurse-submodules' over '--recursive', we'd better just suggest the former. The only other options alias is 'log' and friends' '--mailmap', which is an alias for '--use-mailmap', but the Bash completion helpers for these commands do not use '__gitcomp_builtin', and thus are unnaffected by this change. Test the new behaviour in t9902-completion.sh. As a side effect, this also tests the correct behaviour of GIT_COMPLETION_SHOW_ALL, which was not tested before. Note that since '__gitcomp_builtin' caches the options it shows, we need to re-source the completion script to clear that cache for the second test. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-16 03:55:43 +02:00
'
test_expect_success '__git_complete' '
unset -f __git_wrap__git_main &&
__git_complete foo __git_main &&
__git_have_func __git_wrap__git_main &&
unset -f __git_wrap__git_main &&
__git_complete gf _git_fetch &&
__git_have_func __git_wrap_git_fetch &&
__git_complete foo git &&
__git_have_func __git_wrap__git_main &&
unset -f __git_wrap__git_main &&
__git_complete gd git_diff &&
__git_have_func __git_wrap_git_diff &&
test_must_fail __git_complete ga missing
'
test_done