2012-04-11 21:57:03 +00:00
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
#
|
2020-10-28 02:07:12 +00:00
|
|
|
|
# Copyright (c) 2012-2020 Felipe Contreras
|
2012-04-11 21:57:03 +00:00
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
|
|
test_description='test bash completion'
|
|
|
|
|
|
|
2024-01-15 10:36:02 +00:00
|
|
|
|
# The Bash completion scripts must not print anything to either stdout or
|
|
|
|
|
|
# stderr, which we try to verify. When tracing is enabled without support for
|
|
|
|
|
|
# BASH_XTRACEFD this assertion will fail, so we have to mark the test as
|
|
|
|
|
|
# untraceable with such ancient Bash versions.
|
|
|
|
|
|
test_untraceable=UnfortunatelyYes
|
|
|
|
|
|
|
2024-02-06 21:50:42 +00:00
|
|
|
|
# Override environment and always use master for the default initial branch
|
|
|
|
|
|
# name for these tests, so that rev completion candidates are as expected.
|
|
|
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
|
|
|
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
|
|
2012-05-09 00:44:32 +00:00
|
|
|
|
. ./lib-bash.sh
|
2012-04-11 21:57:03 +00:00
|
|
|
|
|
|
|
|
|
|
complete ()
|
|
|
|
|
|
{
|
|
|
|
|
|
# do nothing
|
|
|
|
|
|
return 0
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2018-05-20 18:40:04 +00:00
|
|
|
|
# Be careful when updating these lists:
|
2013-01-24 23:08:37 +00:00
|
|
|
|
#
|
|
|
|
|
|
# (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",
|
2019-09-04 22:32:39 +00:00
|
|
|
|
# "rebase" and "ls-files" are listed for this.
|
2013-01-24 23:08:37 +00:00
|
|
|
|
|
2019-09-04 22:32:39 +00:00
|
|
|
|
GIT_TESTING_ALL_COMMAND_LIST='add checkout check-attr rebase ls-files'
|
|
|
|
|
|
GIT_TESTING_PORCELAIN_COMMAND_LIST='add checkout rebase'
|
2013-01-24 23:08:37 +00:00
|
|
|
|
|
2012-04-11 21:57:03 +00:00
|
|
|
|
. "$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 )
|
2013-08-21 20:49:32 +00:00
|
|
|
|
test "${1: -1}" = ' ' && _words[${#_words[@]}+1]=''
|
2012-04-11 21:57:03 +00:00
|
|
|
|
(( _cword = ${#_words[@]} - 1 ))
|
2012-06-13 08:08:50 +00:00
|
|
|
|
__git_wrap__git_main && print_comp
|
2012-04-11 21:57:03 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2012-11-11 14:35:53 +00:00
|
|
|
|
# Test high-level completion
|
|
|
|
|
|
# Arguments are:
|
|
|
|
|
|
# 1: typed text so far (cur)
|
|
|
|
|
|
# 2: expected completion
|
2012-04-11 21:57:03 +00:00
|
|
|
|
test_completion ()
|
|
|
|
|
|
{
|
2012-11-11 14:35:56 +00:00
|
|
|
|
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-16 22:41:12 +00:00
|
|
|
|
sed -e 's/Z$//' |sort >expected
|
2012-11-11 14:35:56 +00:00
|
|
|
|
fi &&
|
2024-01-15 10:36:02 +00:00
|
|
|
|
run_completion "$1" >"$TRASH_DIRECTORY"/bash-completion-output 2>&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-16 22:41:12 +00:00
|
|
|
|
sort out >out_sorted &&
|
2024-01-15 10:36:02 +00:00
|
|
|
|
test_cmp expected out_sorted &&
|
|
|
|
|
|
test_must_be_empty "$TRASH_DIRECTORY"/bash-completion-output &&
|
|
|
|
|
|
rm "$TRASH_DIRECTORY"/bash-completion-output
|
2012-04-11 21:57:03 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2012-11-11 14:35:57 +00:00
|
|
|
|
# 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 ()
|
2012-09-26 21:47:51 +00:00
|
|
|
|
{
|
2012-11-11 14:35:58 +00:00
|
|
|
|
local -a COMPREPLY &&
|
2012-11-11 14:35:57 +00:00
|
|
|
|
sed -e 's/Z$//' >expected &&
|
2017-02-03 02:48:11 +00:00
|
|
|
|
local cur="$1" &&
|
2012-11-11 14:35:58 +00:00
|
|
|
|
shift &&
|
|
|
|
|
|
__gitcomp "$@" &&
|
|
|
|
|
|
print_comp &&
|
2012-04-17 10:27:15 +00:00
|
|
|
|
test_cmp expected out
|
2012-09-26 21:47:51 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2013-04-10 06:57:54 +00:00
|
|
|
|
# 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 &&
|
2017-02-03 02:48:11 +00:00
|
|
|
|
local cur="$1" &&
|
2013-04-10 06:57:54 +00:00
|
|
|
|
shift &&
|
|
|
|
|
|
__gitcomp_nl "$@" &&
|
|
|
|
|
|
print_comp &&
|
|
|
|
|
|
test_cmp expected out
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
invalid_variable_name='${foo.bar}'
|
|
|
|
|
|
|
2013-06-17 18:31:51 +00:00
|
|
|
|
actual="$TRASH_DIRECTORY/actual"
|
|
|
|
|
|
|
2017-02-03 02:48:12 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
test_expect_success 'setup for __git_find_repo_path/__gitdir tests' '
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
mkdir -p non-repo &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
git init -b main otherrepo
|
2013-06-17 18:31:51 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - from command line (through $__git_dir)' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/otherrepo/.git" >expected &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
(
|
2017-02-03 02:48:12 +00:00
|
|
|
|
__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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2017-02-03 02:48:28 +00:00
|
|
|
|
) &&
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - .git directory in cwd' '
|
2013-06-17 18:31:51 +00:00
|
|
|
|
echo ".git" >expected &&
|
2017-02-03 02:48:28 +00:00
|
|
|
|
(
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2017-02-03 02:48:28 +00:00
|
|
|
|
) &&
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - .git directory in parent' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/.git" >expected &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
(
|
|
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - cwd is a .git directory' '
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - parent is a .git directory' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/.git" >expected &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
(
|
2018-05-26 06:47:45 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - $GIT_DIR set while .git directory in cwd' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/otherrepo/.git" >expected &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
(
|
2017-02-03 02:48:12 +00:00
|
|
|
|
GIT_DIR="$ROOT/otherrepo/.git" &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - $GIT_DIR set while .git directory in parent' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/otherrepo/.git" >expected &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
(
|
2017-02-03 02:48:12 +00:00
|
|
|
|
GIT_DIR="$ROOT/otherrepo/.git" &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2013-06-17 18:31:51 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00: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 02:48:24 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - non-existing path in $__git_dir' '
|
2017-02-03 02:48:15 +00:00
|
|
|
|
(
|
|
|
|
|
|
__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 02:48:29 +00:00
|
|
|
|
test_must_fail __git_find_repo_path &&
|
|
|
|
|
|
printf "$__git_repo_path" >"$actual"
|
2017-02-03 02:48:15 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - non-existing $GIT_DIR' '
|
2013-06-17 18:31:51 +00:00
|
|
|
|
(
|
2017-02-03 02:48:12 +00:00
|
|
|
|
GIT_DIR="$ROOT/non-existing" &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
test_must_fail __git_find_repo_path &&
|
|
|
|
|
|
printf "$__git_repo_path" >"$actual"
|
2017-02-03 02:48:13 +00:00
|
|
|
|
) &&
|
|
|
|
|
|
test_must_be_empty "$actual"
|
2013-06-17 18:31:51 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - gitfile in cwd' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/otherrepo/.git" >expected &&
|
|
|
|
|
|
echo "gitdir: $ROOT/otherrepo/.git" >subdir/.git &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success '__git_find_repo_path - gitfile in parent' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/otherrepo/.git" >expected &&
|
|
|
|
|
|
echo "gitdir: $ROOT/otherrepo/.git" >subdir/.git &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00:00
|
|
|
|
__git_find_repo_path &&
|
|
|
|
|
|
echo "$__git_repo_path" >"$actual"
|
2013-06-17 18:31:51 +00: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 02:48:29 +00:00
|
|
|
|
test_expect_success SYMLINKS '__git_find_repo_path - resulting path avoids symlinks' '
|
2017-02-03 02:48:12 +00:00
|
|
|
|
echo "$ROOT/otherrepo/.git" >expected &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
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 02:48:29 +00: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 &&
|
2013-06-17 18:31:51 +00:00
|
|
|
|
__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 02:48:29 +00:00
|
|
|
|
|
2019-11-05 17:07:25 +00: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 02:48:29 +00:00
|
|
|
|
(
|
|
|
|
|
|
__git_dir="non-existing" &&
|
|
|
|
|
|
test_must_fail __gitdir >"$actual"
|
|
|
|
|
|
) &&
|
2017-02-03 02:48:13 +00:00
|
|
|
|
test_must_be_empty "$actual"
|
2013-06-17 18:31:51 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
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 02:48:29 +00: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-16 22:41:09 +00:00
|
|
|
|
|
|
|
|
|
|
test_expect_success '__git_dequote - plain unquoted word' '
|
|
|
|
|
|
__git_dequote unquoted-word &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test unquoted-word = "$dequoted_word"
|
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-16 22:41:09 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
# 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" &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test "back'\''\\\"slashes" = "$dequoted_word"
|
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-16 22:41:09 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
# input: sin'gle\' '"quo'ted
|
|
|
|
|
|
# expected: single\ "quoted
|
|
|
|
|
|
test_expect_success '__git_dequote - single quoted' '
|
|
|
|
|
|
__git_dequote "'"sin'gle\\\\' '\\\"quo'ted"'" &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test '\''single\ "quoted'\'' = "$dequoted_word"
|
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-16 22:41:09 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
# input: dou"ble\\" "\"\quot"ed
|
|
|
|
|
|
# expected: double\ "\quoted
|
|
|
|
|
|
test_expect_success '__git_dequote - double quoted' '
|
|
|
|
|
|
__git_dequote '\''dou"ble\\" "\"\quot"ed'\'' &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test '\''double\ "\quoted'\'' = "$dequoted_word"
|
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-16 22:41:09 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
# input: 'open single quote
|
|
|
|
|
|
test_expect_success '__git_dequote - open single quote' '
|
|
|
|
|
|
__git_dequote "'\''open single quote" &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test "open single quote" = "$dequoted_word"
|
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-16 22:41:09 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
# input: "open double quote
|
|
|
|
|
|
test_expect_success '__git_dequote - open double quote' '
|
|
|
|
|
|
__git_dequote "\"open double quote" &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test "open double quote" = "$dequoted_word"
|
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-16 22:41:09 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
|
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 15:29:22 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2012-04-17 10:27:15 +00:00
|
|
|
|
test_expect_success '__gitcomp - trailing space - options' '
|
2012-11-11 14:35:57 +00:00
|
|
|
|
test_gitcomp "--re" "--dry-run --reuse-message= --reedit-message=
|
|
|
|
|
|
--reset-author" <<-EOF
|
2012-04-17 10:27:15 +00:00
|
|
|
|
--reuse-message=Z
|
|
|
|
|
|
--reedit-message=Z
|
|
|
|
|
|
--reset-author Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp - trailing space - config keys' '
|
2012-11-11 14:35:57 +00:00
|
|
|
|
test_gitcomp "br" "branch. branch.autosetupmerge
|
|
|
|
|
|
branch.autosetuprebase browser." <<-\EOF
|
2012-04-17 10:27:15 +00:00
|
|
|
|
branch.Z
|
|
|
|
|
|
branch.autosetupmerge Z
|
|
|
|
|
|
branch.autosetuprebase Z
|
|
|
|
|
|
browser.Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp - option parameter' '
|
2012-11-11 14:35:57 +00:00
|
|
|
|
test_gitcomp "--strategy=re" "octopus ours recursive resolve subtree" \
|
|
|
|
|
|
"" "re" <<-\EOF
|
2012-04-17 10:27:15 +00:00
|
|
|
|
recursive Z
|
|
|
|
|
|
resolve Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp - prefix' '
|
2012-11-11 14:35:57 +00:00
|
|
|
|
test_gitcomp "branch.me" "remote merge mergeoptions rebase" \
|
|
|
|
|
|
"branch.maint." "me" <<-\EOF
|
2012-04-17 10:27:15 +00:00
|
|
|
|
branch.maint.merge Z
|
|
|
|
|
|
branch.maint.mergeoptions Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp - suffix' '
|
2020-06-25 12:18:59 +00:00
|
|
|
|
test_gitcomp "branch.me" "master maint next seen" "branch." \
|
2012-11-11 14:35:57 +00:00
|
|
|
|
"ma" "." <<-\EOF
|
2012-04-17 10:27:15 +00:00
|
|
|
|
branch.master.Z
|
|
|
|
|
|
branch.maint.Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2018-06-06 09:41:39 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2021-08-16 09:10:23 +00:00
|
|
|
|
test_expect_success '__gitcomp - equal skip' '
|
|
|
|
|
|
test_gitcomp "--option=" "--option=" <<-\EOF &&
|
|
|
|
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
test_gitcomp "option=" "option=" <<-\EOF
|
|
|
|
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2013-04-10 06:57:55 +00:00
|
|
|
|
test_expect_success '__gitcomp - doesnt fail because of invalid variable name' '
|
2013-04-10 06:57:54 +00:00
|
|
|
|
__gitcomp "$invalid_variable_name"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
read -r -d "" refs <<-\EOF
|
2020-09-26 21:04:22 +00:00
|
|
|
|
main
|
2013-04-10 06:57:54 +00:00
|
|
|
|
maint
|
|
|
|
|
|
next
|
2020-06-25 12:18:59 +00:00
|
|
|
|
seen
|
2013-04-10 06:57:54 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp_nl - trailing space' '
|
|
|
|
|
|
test_gitcomp_nl "m" "$refs" <<-EOF
|
2020-09-26 21:04:22 +00:00
|
|
|
|
main Z
|
2013-04-10 06:57:54 +00:00
|
|
|
|
maint Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp_nl - prefix' '
|
|
|
|
|
|
test_gitcomp_nl "--fixup=m" "$refs" "--fixup=" "m" <<-EOF
|
2020-09-26 21:04:22 +00:00
|
|
|
|
--fixup=main Z
|
2013-04-10 06:57:54 +00:00
|
|
|
|
--fixup=maint Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp_nl - suffix' '
|
|
|
|
|
|
test_gitcomp_nl "branch.ma" "$refs" "branch." "ma" "." <<-\EOF
|
2020-09-26 21:04:22 +00:00
|
|
|
|
branch.main.Z
|
2013-04-10 06:57:54 +00:00
|
|
|
|
branch.maint.Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__gitcomp_nl - no suffix' '
|
|
|
|
|
|
test_gitcomp_nl "ma" "$refs" "" "ma" "" <<-\EOF
|
2020-09-26 21:04:22 +00:00
|
|
|
|
mainZ
|
2013-04-10 06:57:54 +00:00
|
|
|
|
maintZ
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2013-04-10 06:57:55 +00:00
|
|
|
|
test_expect_success '__gitcomp_nl - doesnt fail because of invalid variable name' '
|
2013-04-10 06:57:54 +00:00
|
|
|
|
__gitcomp_nl "$invalid_variable_name"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2015-03-04 14:10:28 +00:00
|
|
|
|
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 &&
|
2017-02-03 02:48:28 +00:00
|
|
|
|
(
|
|
|
|
|
|
__git_remotes >actual
|
|
|
|
|
|
) &&
|
2015-03-04 14:10:28 +00:00
|
|
|
|
test_cmp expect actual
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2017-02-03 02:48:18 +00:00
|
|
|
|
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 &&
|
2017-02-03 02:48:28 +00:00
|
|
|
|
(
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
__git_is_configured_remote remote_2 &&
|
2017-02-03 02:48:28 +00:00
|
|
|
|
test_must_fail __git_is_configured_remote non-existent
|
|
|
|
|
|
)
|
2017-02-03 02:48:18 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
test_expect_success 'setup for ref completion' '
|
|
|
|
|
|
git commit --allow-empty -m initial &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
git branch -M main &&
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
git branch matching-branch &&
|
|
|
|
|
|
git tag matching-tag &&
|
|
|
|
|
|
(
|
|
|
|
|
|
cd otherrepo &&
|
|
|
|
|
|
git commit --allow-empty -m initial &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
git branch -m main main-in-other &&
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
matching-branch
|
|
|
|
|
|
other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
matching-tag
|
|
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
cur= &&
|
|
|
|
|
|
__git_refs >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__git_refs - full refs' '
|
|
|
|
|
|
cat >expected <<-EOF &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
refs/heads/main
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
refs/remotes/other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
refs/tags/matching-tag
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
refs/heads/main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
HEAD
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
refs/heads/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
refs/heads/main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
refs/tags/tag-in-other
|
|
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
cur=refs/ &&
|
|
|
|
|
|
__git_refs other >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2017-02-03 02:48:17 +00:00
|
|
|
|
test_expect_success '__git_refs - configured remote - repo given on the command line' '
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
|
|
HEAD
|
|
|
|
|
|
branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
cd thirdrepo &&
|
|
|
|
|
|
__git_dir="$ROOT/.git" &&
|
|
|
|
|
|
cur= &&
|
|
|
|
|
|
__git_refs other >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2017-02-03 02:48:17 +00:00
|
|
|
|
test_expect_success '__git_refs - configured remote - full refs - repo given on the command line' '
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
HEAD
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
refs/heads/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
refs/heads/main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
refs/tags/tag-in-other
|
|
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
cd thirdrepo &&
|
|
|
|
|
|
__git_dir="$ROOT/.git" &&
|
|
|
|
|
|
cur=refs/ &&
|
|
|
|
|
|
__git_refs other >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2017-02-03 02:48:18 +00:00
|
|
|
|
test_expect_success '__git_refs - configured remote - remote name matches a directory' '
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
|
|
HEAD
|
|
|
|
|
|
branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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 02:48:20 +00:00
|
|
|
|
test_expect_success '__git_refs - URL remote' '
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
|
|
HEAD
|
|
|
|
|
|
branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
HEAD
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
refs/heads/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
refs/heads/main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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 02:48:20 +00:00
|
|
|
|
test_expect_success '__git_refs - non-existing remote' '
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
(
|
|
|
|
|
|
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 02:48:20 +00:00
|
|
|
|
test_expect_success '__git_refs - non-existing URL remote' '
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
(
|
|
|
|
|
|
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"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2017-02-03 02:48:19 +00:00
|
|
|
|
test_expect_success '__git_refs - not in a git repository' '
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
(
|
|
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
matching-branch
|
|
|
|
|
|
other/ambiguous
|
|
|
|
|
|
other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
remote/ambiguous
|
|
|
|
|
|
remote/branch-in-remote
|
|
|
|
|
|
matching-tag
|
|
|
|
|
|
branch-in-other
|
|
|
|
|
|
branch-in-remote
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
for remote_ref in refs/remotes/other/ambiguous \
|
|
|
|
|
|
refs/remotes/remote/ambiguous \
|
|
|
|
|
|
refs/remotes/remote/branch-in-remote
|
|
|
|
|
|
do
|
2020-12-17 01:07:09 +00:00
|
|
|
|
git update-ref $remote_ref main &&
|
2021-12-09 05:11:15 +00:00
|
|
|
|
test_when_finished "git update-ref -d $remote_ref" || return 1
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
done &&
|
|
|
|
|
|
(
|
|
|
|
|
|
cur= &&
|
|
|
|
|
|
__git_refs "" 1 >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2017-03-23 15:29:13 +00:00
|
|
|
|
test_expect_success '__git_refs - after --opt=' '
|
|
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
|
|
HEAD
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main
|
2017-03-23 15:29:13 +00:00
|
|
|
|
matching-branch
|
|
|
|
|
|
other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other
|
2017-03-23 15:29:13 +00:00
|
|
|
|
matching-tag
|
|
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
cur="--opt=" &&
|
|
|
|
|
|
__git_refs "" "" "" "" >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__git_refs - after --opt= - full refs' '
|
|
|
|
|
|
cat >expected <<-EOF &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
refs/heads/main
|
2017-03-23 15:29:13 +00:00
|
|
|
|
refs/heads/matching-branch
|
|
|
|
|
|
refs/remotes/other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
refs/remotes/other/main-in-other
|
2017-03-23 15:29:13 +00:00
|
|
|
|
refs/tags/matching-tag
|
|
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
cur="--opt=refs/" &&
|
|
|
|
|
|
__git_refs "" "" "" refs/ >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-12-01 00:46:48 +00:00
|
|
|
|
test_expect_success '__git refs - excluding refs' '
|
2017-03-23 15:29:15 +00:00
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
|
|
^HEAD
|
2020-12-17 01:07:09 +00:00
|
|
|
|
^main
|
2017-03-23 15:29:15 +00:00
|
|
|
|
^matching-branch
|
|
|
|
|
|
^other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
^other/main-in-other
|
2017-03-23 15:29:15 +00:00
|
|
|
|
^matching-tag
|
|
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
cur=^ &&
|
|
|
|
|
|
__git_refs >"$actual"
|
|
|
|
|
|
) &&
|
|
|
|
|
|
test_cmp expected "$actual"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-12-01 00:46:48 +00:00
|
|
|
|
test_expect_success '__git refs - excluding full refs' '
|
2017-03-23 15:29:15 +00:00
|
|
|
|
cat >expected <<-EOF &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
^refs/heads/main
|
2017-03-23 15:29:15 +00:00
|
|
|
|
^refs/heads/matching-branch
|
|
|
|
|
|
^refs/remotes/other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
^refs/remotes/other/main-in-other
|
2017-03-23 15:29:15 +00:00
|
|
|
|
^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 15:29:18 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2019-11-05 17:07:25 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
|
|
HEAD
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
matching-branch
|
|
|
|
|
|
matching/branch
|
|
|
|
|
|
other/branch-in-other
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:18 +00:00
|
|
|
|
other/matching/branch-in-other
|
|
|
|
|
|
matching-tag
|
|
|
|
|
|
matching/tag
|
|
|
|
|
|
EOF
|
|
|
|
|
|
(
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:18 +00: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 &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:18 +00: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 &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:18 +00: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 &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:18 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
git update-ref $remote_ref main &&
|
2021-12-09 05:11:15 +00:00
|
|
|
|
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 15:29:18 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:22 +00:00
|
|
|
|
cat >expected <<-EOF &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:22 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
(
|
2020-10-23 14:00:04 +00:00
|
|
|
|
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 15:29:22 +00: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 15:29:12 +00:00
|
|
|
|
test_expect_success '__git_complete_refs - simple' '
|
|
|
|
|
|
sed -e "s/Z$//" >expected <<-EOF &&
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
(
|
2018-07-02 00:24:04 +00:00
|
|
|
|
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 15:29:12 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00:00
|
|
|
|
matching-tag Z
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
(
|
2018-07-02 00:24:04 +00:00
|
|
|
|
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 15:29:12 +00: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.
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00:00
|
|
|
|
matching-branch.
|
|
|
|
|
|
other/branch-in-other.
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:12 +00: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 15:29:14 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:14 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
+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 15:29:14 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 15:29:14 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
+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 15:29:14 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-27 21:06:49 +00:00
|
|
|
|
test_expect_success '__git_complete_worktree_paths' '
|
|
|
|
|
|
test_when_finished "git worktree remove other_wt" &&
|
|
|
|
|
|
git worktree add --orphan other_wt &&
|
|
|
|
|
|
run_completion "git worktree remove " &&
|
|
|
|
|
|
grep other_wt out
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__git_complete_worktree_paths - not a git repository' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd non-repo &&
|
|
|
|
|
|
GIT_CEILING_DIRECTORIES="$ROOT" &&
|
|
|
|
|
|
export GIT_CEILING_DIRECTORIES &&
|
|
|
|
|
|
test_completion "git worktree remove " ""
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '__git_complete_worktree_paths with -C' '
|
|
|
|
|
|
test_when_finished "git -C otherrepo worktree remove otherrepo_wt" &&
|
|
|
|
|
|
git -C otherrepo worktree add --orphan otherrepo_wt &&
|
|
|
|
|
|
run_completion "git -C otherrepo worktree remove " &&
|
|
|
|
|
|
grep otherrepo_wt out
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: improve completion for git switch with no options
Add a new --mode option to __git_complete_refs, which allows changing
the behavior to call __git_heads instead of __git_refs.
By passing --mode=heads, __git_complete_refs will only output local
branches. This enables using "--mode=heads --dwim" to enable listing
local branches and the remote unique branch names for DWIM.
Refactor completion support to use the new mode option, rather than
calling __git_heads directly. This has the advantage that we can now
correctly allow local branches along with suitable DWIM refs, rather
than only allowing DWIM when we complete all references.
Choose what mode it uses when calling __git_complete_refs. If -d or
--detach have been provided, then simply complete all refs, but
*without* the DWIM option as these DWIM names won't work properly in
--detach mode.
Otherwise, call __git_complete_refs with the default dwim_opt value and
use the new "heads" mode.
In this way, the basic support for completing just "git switch <TAB>"
will result in only local branches and remote unique names for DWIM.
The basic no-options tests for git switch, as well as several of the
-c/-C tests now pass, so remove the known breakage tags.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 18:10:44 +00:00
|
|
|
|
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 18:10:33 +00:00
|
|
|
|
test_completion "git switch " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:33 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-06 21:50:43 +00:00
|
|
|
|
test_expect_success 'git bisect - when not bisecting, complete only replay and start subcommands' '
|
|
|
|
|
|
test_completion "git bisect " <<-\EOF
|
|
|
|
|
|
replay Z
|
|
|
|
|
|
start Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-06 21:50:45 +00:00
|
|
|
|
test_expect_success 'git bisect - complete options to start subcommand' '
|
|
|
|
|
|
test_completion "git bisect start --" <<-\EOF
|
|
|
|
|
|
--term-new Z
|
|
|
|
|
|
--term-bad Z
|
|
|
|
|
|
--term-old Z
|
|
|
|
|
|
--term-good Z
|
|
|
|
|
|
--no-checkout Z
|
|
|
|
|
|
--first-parent Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-06 21:50:43 +00:00
|
|
|
|
test_expect_success 'setup for git-bisect tests requiring a repo' '
|
|
|
|
|
|
git init git-bisect &&
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
echo "initial contents" >file &&
|
|
|
|
|
|
git add file &&
|
|
|
|
|
|
git commit -am "Initial commit" &&
|
|
|
|
|
|
git tag initial &&
|
|
|
|
|
|
echo "new line" >>file &&
|
|
|
|
|
|
git commit -am "First change" &&
|
|
|
|
|
|
echo "another new line" >>file &&
|
|
|
|
|
|
git commit -am "Second change" &&
|
|
|
|
|
|
git tag final
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git bisect - start subcommand arguments before double-dash are completed as revs' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
test_completion "git bisect start " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
|
|
|
|
|
final Z
|
|
|
|
|
|
initial Z
|
|
|
|
|
|
master Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
# Note that these arguments are <pathspec>s, which in practice the fallback
|
|
|
|
|
|
# completion (not the git completion) later ends up completing as paths.
|
|
|
|
|
|
test_expect_success 'git bisect - start subcommand arguments after double-dash are not completed' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
test_completion "git bisect start final initial -- " ""
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup for git-bisect tests requiring ongoing bisection' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
git bisect start --term-new=custom_new --term-old=custom_old final initial
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git-bisect - when bisecting all subcommands are candidates' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
test_completion "git bisect " <<-\EOF
|
|
|
|
|
|
start Z
|
|
|
|
|
|
bad Z
|
2024-02-06 21:50:44 +00:00
|
|
|
|
custom_new Z
|
|
|
|
|
|
custom_old Z
|
2024-02-06 21:50:43 +00:00
|
|
|
|
new Z
|
|
|
|
|
|
good Z
|
|
|
|
|
|
old Z
|
2024-02-06 21:50:44 +00:00
|
|
|
|
terms Z
|
2024-02-06 21:50:43 +00:00
|
|
|
|
skip Z
|
|
|
|
|
|
reset Z
|
|
|
|
|
|
visualize Z
|
|
|
|
|
|
replay Z
|
|
|
|
|
|
log Z
|
|
|
|
|
|
run Z
|
|
|
|
|
|
help Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-06 21:50:44 +00:00
|
|
|
|
test_expect_success 'git-bisect - options to terms subcommand are candidates' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
test_completion "git bisect terms --" <<-\EOF
|
|
|
|
|
|
--term-bad Z
|
|
|
|
|
|
--term-good Z
|
|
|
|
|
|
--term-new Z
|
|
|
|
|
|
--term-old Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-06 21:50:47 +00:00
|
|
|
|
test_expect_success 'git-bisect - git-log options to visualize subcommand are candidates' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
# The completion used for git-log and here does not complete
|
|
|
|
|
|
# every git-log option, so rather than hope to stay in sync
|
|
|
|
|
|
# with exactly what it does we will just spot-test here.
|
|
|
|
|
|
test_completion "git bisect visualize --sta" <<-\EOF &&
|
|
|
|
|
|
--stat Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
test_completion "git bisect visualize --summar" <<-\EOF
|
|
|
|
|
|
--summary Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-06 21:50:48 +00:00
|
|
|
|
test_expect_success 'git-bisect - view subcommand is not a candidate' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
test_completion "git bisect vi" <<-\EOF
|
|
|
|
|
|
visualize Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git-bisect - existing view subcommand is recognized and enables completion of git-log options' '
|
|
|
|
|
|
(
|
|
|
|
|
|
cd git-bisect &&
|
|
|
|
|
|
# The completion used for git-log and here does not complete
|
|
|
|
|
|
# every git-log option, so rather than hope to stay in sync
|
|
|
|
|
|
# with exactly what it does we will just spot-test here.
|
|
|
|
|
|
test_completion "git bisect view --sta" <<-\EOF &&
|
|
|
|
|
|
--stat Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
test_completion "git bisect view --summar" <<-\EOF
|
|
|
|
|
|
--summary Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
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 18:10:33 +00:00
|
|
|
|
test_expect_success 'git checkout - completes refs and unique remote branches for DWIM' '
|
|
|
|
|
|
test_completion "git checkout " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:33 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:33 +00: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 18:10:34 +00:00
|
|
|
|
test_expect_success 'git switch - with --no-guess, complete only local branches' '
|
|
|
|
|
|
test_completion "git switch --no-guess " <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: improve completion for git switch with no options
Add a new --mode option to __git_complete_refs, which allows changing
the behavior to call __git_heads instead of __git_refs.
By passing --mode=heads, __git_complete_refs will only output local
branches. This enables using "--mode=heads --dwim" to enable listing
local branches and the remote unique branch names for DWIM.
Refactor completion support to use the new mode option, rather than
calling __git_heads directly. This has the advantage that we can now
correctly allow local branches along with suitable DWIM refs, rather
than only allowing DWIM when we complete all references.
Choose what mode it uses when calling __git_complete_refs. If -d or
--detach have been provided, then simply complete all refs, but
*without* the DWIM option as these DWIM names won't work properly in
--detach mode.
Otherwise, call __git_complete_refs with the default dwim_opt value and
use the new "heads" mode.
In this way, the basic support for completing just "git switch <TAB>"
will result in only local branches and remote unique names for DWIM.
The basic no-options tests for git switch, as well as several of the
-c/-C tests now pass, so remove the known breakage tags.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 18:10:44 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
GIT_COMPLETION_CHECKOUT_NO_GUESS=1 test_completion "git switch --guess " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: improve completion for git switch with no options
Add a new --mode option to __git_complete_refs, which allows changing
the behavior to call __git_heads instead of __git_refs.
By passing --mode=heads, __git_complete_refs will only output local
branches. This enables using "--mode=heads --dwim" to enable listing
local branches and the remote unique branch names for DWIM.
Refactor completion support to use the new mode option, rather than
calling __git_heads directly. This has the advantage that we can now
correctly allow local branches along with suitable DWIM refs, rather
than only allowing DWIM when we complete all references.
Choose what mode it uses when calling __git_complete_refs. If -d or
--detach have been provided, then simply complete all refs, but
*without* the DWIM option as these DWIM names won't work properly in
--detach mode.
Otherwise, call __git_complete_refs with the default dwim_opt value and
use the new "heads" mode.
In this way, the basic support for completing just "git switch <TAB>"
will result in only local branches and remote unique names for DWIM.
The basic no-options tests for git switch, as well as several of the
-c/-C tests now pass, so remove the known breakage tags.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 18:10:44 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
test_completion "git switch --no-guess --guess " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00: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 18:10:43 +00: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 18:10:34 +00:00
|
|
|
|
test_completion "git switch --guess --no-guess " <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00: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 18:10:43 +00: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 18:10:34 +00:00
|
|
|
|
GIT_COMPLETION_CHECKOUT_NO_GUESS=1 test_completion "git checkout --guess " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git checkout - with --no-guess, only completes refs' '
|
|
|
|
|
|
test_completion "git checkout --no-guess " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00: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 18:10:43 +00: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 18:10:34 +00:00
|
|
|
|
test_completion "git checkout --no-guess --guess " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00: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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
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 18:10:34 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-10-08 05:48:15 +00:00
|
|
|
|
test_expect_success 'git checkout - with checkout.guess = false, only completes refs' '
|
|
|
|
|
|
test_config checkout.guess false &&
|
|
|
|
|
|
test_completion "git checkout " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-10-08 05:48:15 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:35 +00:00
|
|
|
|
test_expect_success 'git switch - with --detach, complete all references' '
|
|
|
|
|
|
test_completion "git switch --detach " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:45 +00:00
|
|
|
|
test_expect_success 'git checkout - with --detach, complete only references' '
|
2020-05-28 18:10:35 +00:00
|
|
|
|
test_completion "git checkout --detach " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2022-02-07 17:31:43 +00:00
|
|
|
|
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
|
2022-02-07 17:31:44 +00:00
|
|
|
|
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/
|
2022-02-07 17:31:43 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
) &&
|
|
|
|
|
|
|
|
|
|
|
|
(
|
|
|
|
|
|
cd sparse-checkout/folder1 &&
|
2022-02-07 17:31:44 +00:00
|
|
|
|
test_completion "git sparse-checkout add 0" <<-\EOF
|
|
|
|
|
|
0/
|
2022-02-07 17:31:43 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2022-02-07 17:31:45 +00:00
|
|
|
|
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"
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
t9902: split test to run on appropriate systems
The "FUNNYNAMES" test prerequisite passes on Cygwin, as the Cygwin
file system interface has a workaround for the underlying operating
system's lack of support for tabs, newlines or quotes. However, it does
not add support for backslash, which is treated as a directory
separator, meaning one of the tests added by 48803821b1 ("completion:
handle unusual characters for sparse-checkout", 2022-02-07) will fail on
Cygwin.
To avoid this failure while still getting maximal test coverage, split
that test into two: test handling of paths that include tabs on anything
that has the FUNNYNAMES prerequisite, but skip testing handling of paths
that include backslashes unless both FUNNYNAMES is set and the system is
not Cygwin.
It might be nice to have more granularity than "FUNNYNAMES" and its
sibling "FUNNIERNAMES" provide, so that tests could be run based on
specific individual characters supported by the file system being
tested, but that seems like it would make the prerequisite checks in
this area much more verbose for very little gain.
Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-08 09:53:53 +00:00
|
|
|
|
# use FUNNYNAMES to avoid running on Windows, which doesn't permit tabs in paths
|
|
|
|
|
|
test_expect_success FUNNYNAMES 'cone mode sparse-checkout completes directory names with tabs' '
|
2022-02-07 17:31:45 +00:00
|
|
|
|
# reset sparse-checkout
|
|
|
|
|
|
git -C sparse-checkout sparse-checkout disable &&
|
|
|
|
|
|
(
|
|
|
|
|
|
cd sparse-checkout &&
|
|
|
|
|
|
mkdir "$(printf "directory\twith\ttabs")" &&
|
|
|
|
|
|
>"$(printf "directory\twith\ttabs")/randomfile" &&
|
|
|
|
|
|
git add . &&
|
t9902: split test to run on appropriate systems
The "FUNNYNAMES" test prerequisite passes on Cygwin, as the Cygwin
file system interface has a workaround for the underlying operating
system's lack of support for tabs, newlines or quotes. However, it does
not add support for backslash, which is treated as a directory
separator, meaning one of the tests added by 48803821b1 ("completion:
handle unusual characters for sparse-checkout", 2022-02-07) will fail on
Cygwin.
To avoid this failure while still getting maximal test coverage, split
that test into two: test handling of paths that include tabs on anything
that has the FUNNYNAMES prerequisite, but skip testing handling of paths
that include backslashes unless both FUNNYNAMES is set and the system is
not Cygwin.
It might be nice to have more granularity than "FUNNYNAMES" and its
sibling "FUNNIERNAMES" provide, so that tests could be run based on
specific individual characters supported by the file system being
tested, but that seems like it would make the prerequisite checks in
this area much more verbose for very little gain.
Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-08 09:53:53 +00:00
|
|
|
|
git commit -m "Add directory with tabs" &&
|
|
|
|
|
|
git sparse-checkout set --cone \
|
2022-02-07 17:31:45 +00:00
|
|
|
|
"$(printf "directory\twith\ttabs")" &&
|
|
|
|
|
|
test_completion "git sparse-checkout add dir" <<-\EOF &&
|
|
|
|
|
|
directory with tabs/
|
|
|
|
|
|
EOF
|
|
|
|
|
|
rm -rf "$(printf "directory\twith\ttabs")" &&
|
|
|
|
|
|
git add . &&
|
t9902: split test to run on appropriate systems
The "FUNNYNAMES" test prerequisite passes on Cygwin, as the Cygwin
file system interface has a workaround for the underlying operating
system's lack of support for tabs, newlines or quotes. However, it does
not add support for backslash, which is treated as a directory
separator, meaning one of the tests added by 48803821b1 ("completion:
handle unusual characters for sparse-checkout", 2022-02-07) will fail on
Cygwin.
To avoid this failure while still getting maximal test coverage, split
that test into two: test handling of paths that include tabs on anything
that has the FUNNYNAMES prerequisite, but skip testing handling of paths
that include backslashes unless both FUNNYNAMES is set and the system is
not Cygwin.
It might be nice to have more granularity than "FUNNYNAMES" and its
sibling "FUNNIERNAMES" provide, so that tests could be run based on
specific individual characters supported by the file system being
tested, but that seems like it would make the prerequisite checks in
this area much more verbose for very little gain.
Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-08 09:53:53 +00:00
|
|
|
|
git commit -m "Remove directory with tabs"
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
# use FUNNYNAMES to avoid running on Windows, and !CYGWIN for Cygwin, as neither permit backslashes in paths
|
|
|
|
|
|
test_expect_success FUNNYNAMES,!CYGWIN 'cone mode sparse-checkout completes directory names with backslashes' '
|
|
|
|
|
|
# reset sparse-checkout
|
|
|
|
|
|
git -C sparse-checkout sparse-checkout disable &&
|
|
|
|
|
|
(
|
|
|
|
|
|
cd sparse-checkout &&
|
|
|
|
|
|
mkdir "directory\with\backslashes" &&
|
|
|
|
|
|
>"directory\with\backslashes/randomfile" &&
|
|
|
|
|
|
git add . &&
|
|
|
|
|
|
git commit -m "Add directory with backslashes" &&
|
|
|
|
|
|
git sparse-checkout set --cone \
|
|
|
|
|
|
"directory\with\backslashes" &&
|
|
|
|
|
|
test_completion "git sparse-checkout add dir" <<-\EOF &&
|
|
|
|
|
|
directory\with\backslashes/
|
|
|
|
|
|
EOF
|
|
|
|
|
|
rm -rf "directory\with\backslashes" &&
|
|
|
|
|
|
git add . &&
|
|
|
|
|
|
git commit -m "Remove directory with backslashes"
|
2022-02-07 17:31:45 +00:00
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: avoid user confusion in non-cone mode
It is tempting to think of "files and directories" of the current
directory as valid inputs to the add and set subcommands of git
sparse-checkout. However, in non-cone mode, they often aren't and using
them as potential completions leads to *many* forms of confusion:
Issue #1. It provides the *wrong* files and directories.
For
git sparse-checkout add
we always want to add files and directories not currently in our sparse
checkout, which means we want file and directories not currently present
in the current working tree. Providing the files and directories
currently present is thus always wrong.
For
git sparse-checkout set
we have a similar problem except in the subset of cases where we are
trying to narrow our checkout to a strict subset of what we already
have. That is not a very common scenario, especially since it often
does not even happen to be true for the first use of the command; for
years we required users to create a sparse-checkout via
git sparse-checkout init
git sparse-checkout set <args...>
(or use a clone option that did the init step for you at clone time).
The init command creates a minimal sparse-checkout with just the
top-level directory present, meaning the set command has to be used to
expand the checkout. Thus, only in a special and perhaps unusual cases
would any of the suggestions from normal file and directory completion
be appropriate.
Issue #2: Suggesting patterns that lead to warnings is unfriendly.
If the user specifies any regular file and omits the leading '/', then
the sparse-checkout command will warn the user that their command is
problematic and suggest they use a leading slash instead.
Issue #3: Completion gets confused by leading '/', and provides wrong paths.
Users often want to anchor their patterns to the toplevel of the
repository, especially when listing individual files. There are a
number of reasons for this, but notably even sparse-checkout encourages
them to do so (as noted above). However, if users do so (via adding a
leading '/' to their pattern), then bash completion will interpret the
leading slash not as a request for a path at the toplevel of the
repository, but as a request for a path at the root of the filesytem.
That means at best that completion cannot help with such paths, and if
it does find any completions, they are almost guaranteed to be wrong.
Issue #4: Suggesting invalid patterns from subdirectories is unfriendly.
There is no per-directory equivalent to .gitignore with
sparse-checkouts. There is only a single worktree-global
$GIT_DIR/info/sparse-checkout file. As such, paths to files must be
specified relative to the toplevel of a repository. Providing
suggestions of paths that are relative to the current working directory,
as bash completion defaults to, is wrong when the current working
directory is not the worktree toplevel directory.
Issue #5: Paths with special characters will be interpreted incorrectly
The entries in the sparse-checkout file are patterns, not paths. While
most paths also qualify as patterns (though even in such cases it would
be better for users to not use them directly but prefix them with a
leading '/'), there are a variety of special characters that would need
special escaping beyond the normal shell escaping: '*', '?', '\', '[',
']', and any leading '#' or '!'. If completion suggests any such paths,
users will likely expect them to be treated as an exact path rather than
as a pattern that might match some number of files other than 1.
However, despite the first four issues, we can note that _if_ users are
using tab completion, then they are probably trying to specify a path in
the index. As such, we transform their argument into a top-level-rooted
pattern that matches such a file. For example, if they type:
git sparse-checkout add Make<TAB>
we could "complete" to
git sparse-checkout add /Makefile
or, if they ran from the Documentation/technical/ subdirectory:
git sparse-checkout add m<TAB>
we could "complete" it to:
git sparse-checkout add /Documentation/technical/multi-pack-index.txt
Note in both cases I use "complete" in quotes, because we actually add
characters both before and after the argument in question, so we are
kind of abusing "bash completions" to be "bash completions AND
beginnings".
The fifth issue is a bit stickier, especially when you consider that we
not only need to deal with escaping issues because of special meanings
of patterns in sparse-checkout & gitignore files, but also that we need
to consider escaping issues due to ls-files needing to sometimes quote
or escape characters, and because the shell needs to escape some
characters. The multiple interacting forms of escaping could get ugly;
this patch makes no attempt to do so and simply documents that we
decided to not deal with those corner cases for now but at least get the
common cases right.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-03 05:57:04 +00:00
|
|
|
|
test_expect_success 'non-cone mode sparse-checkout gives rooted paths' '
|
2022-02-07 17:31:43 +00:00
|
|
|
|
# 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
|
completion: avoid user confusion in non-cone mode
It is tempting to think of "files and directories" of the current
directory as valid inputs to the add and set subcommands of git
sparse-checkout. However, in non-cone mode, they often aren't and using
them as potential completions leads to *many* forms of confusion:
Issue #1. It provides the *wrong* files and directories.
For
git sparse-checkout add
we always want to add files and directories not currently in our sparse
checkout, which means we want file and directories not currently present
in the current working tree. Providing the files and directories
currently present is thus always wrong.
For
git sparse-checkout set
we have a similar problem except in the subset of cases where we are
trying to narrow our checkout to a strict subset of what we already
have. That is not a very common scenario, especially since it often
does not even happen to be true for the first use of the command; for
years we required users to create a sparse-checkout via
git sparse-checkout init
git sparse-checkout set <args...>
(or use a clone option that did the init step for you at clone time).
The init command creates a minimal sparse-checkout with just the
top-level directory present, meaning the set command has to be used to
expand the checkout. Thus, only in a special and perhaps unusual cases
would any of the suggestions from normal file and directory completion
be appropriate.
Issue #2: Suggesting patterns that lead to warnings is unfriendly.
If the user specifies any regular file and omits the leading '/', then
the sparse-checkout command will warn the user that their command is
problematic and suggest they use a leading slash instead.
Issue #3: Completion gets confused by leading '/', and provides wrong paths.
Users often want to anchor their patterns to the toplevel of the
repository, especially when listing individual files. There are a
number of reasons for this, but notably even sparse-checkout encourages
them to do so (as noted above). However, if users do so (via adding a
leading '/' to their pattern), then bash completion will interpret the
leading slash not as a request for a path at the toplevel of the
repository, but as a request for a path at the root of the filesytem.
That means at best that completion cannot help with such paths, and if
it does find any completions, they are almost guaranteed to be wrong.
Issue #4: Suggesting invalid patterns from subdirectories is unfriendly.
There is no per-directory equivalent to .gitignore with
sparse-checkouts. There is only a single worktree-global
$GIT_DIR/info/sparse-checkout file. As such, paths to files must be
specified relative to the toplevel of a repository. Providing
suggestions of paths that are relative to the current working directory,
as bash completion defaults to, is wrong when the current working
directory is not the worktree toplevel directory.
Issue #5: Paths with special characters will be interpreted incorrectly
The entries in the sparse-checkout file are patterns, not paths. While
most paths also qualify as patterns (though even in such cases it would
be better for users to not use them directly but prefix them with a
leading '/'), there are a variety of special characters that would need
special escaping beyond the normal shell escaping: '*', '?', '\', '[',
']', and any leading '#' or '!'. If completion suggests any such paths,
users will likely expect them to be treated as an exact path rather than
as a pattern that might match some number of files other than 1.
However, despite the first four issues, we can note that _if_ users are
using tab completion, then they are probably trying to specify a path in
the index. As such, we transform their argument into a top-level-rooted
pattern that matches such a file. For example, if they type:
git sparse-checkout add Make<TAB>
we could "complete" to
git sparse-checkout add /Makefile
or, if they ran from the Documentation/technical/ subdirectory:
git sparse-checkout add m<TAB>
we could "complete" it to:
git sparse-checkout add /Documentation/technical/multi-pack-index.txt
Note in both cases I use "complete" in quotes, because we actually add
characters both before and after the argument in question, so we are
kind of abusing "bash completions" to be "bash completions AND
beginnings".
The fifth issue is a bit stickier, especially when you consider that we
not only need to deal with escaping issues because of special meanings
of patterns in sparse-checkout & gitignore files, but also that we need
to consider escaping issues due to ls-files needing to sometimes quote
or escape characters, and because the shell needs to escape some
characters. The multiple interacting forms of escaping could get ugly;
this patch makes no attempt to do so and simply documents that we
decided to not deal with those corner cases for now but at least get the
common cases right.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-03 05:57:04 +00:00
|
|
|
|
/folder1/0/1/t.txt Z
|
|
|
|
|
|
/folder1/expected Z
|
|
|
|
|
|
/folder1/out Z
|
|
|
|
|
|
/folder1/out_sorted Z
|
|
|
|
|
|
/folder2/0/t.txt Z
|
|
|
|
|
|
/folder3/t.txt Z
|
2022-02-07 17:31:43 +00:00
|
|
|
|
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
|
2022-02-07 17:31:44 +00:00
|
|
|
|
folder1/
|
|
|
|
|
|
folder2/
|
|
|
|
|
|
folder3/
|
2022-02-07 17:31:43 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:35 +00:00
|
|
|
|
test_expect_success 'git switch - with -d, complete all references' '
|
|
|
|
|
|
test_completion "git switch -d " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:45 +00:00
|
|
|
|
test_expect_success 'git checkout - with -d, complete only references' '
|
2020-05-28 18:10:35 +00:00
|
|
|
|
test_completion "git checkout -d " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:35 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:46 +00:00
|
|
|
|
test_expect_success 'git switch - with --track, complete only remote branches' '
|
2023-09-08 12:28:43 +00:00
|
|
|
|
test_completion "git switch --track " <<-\EOF &&
|
|
|
|
|
|
other/branch-in-other Z
|
|
|
|
|
|
other/main-in-other Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
test_completion "git switch -t " <<-\EOF
|
2020-05-28 18:10:36 +00:00
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:36 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:46 +00:00
|
|
|
|
test_expect_success 'git checkout - with --track, complete only remote branches' '
|
2023-09-08 12:28:43 +00:00
|
|
|
|
test_completion "git checkout --track " <<-\EOF &&
|
|
|
|
|
|
other/branch-in-other Z
|
|
|
|
|
|
other/main-in-other Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
test_completion "git checkout -t " <<-\EOF
|
2020-05-28 18:10:36 +00:00
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:36 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git switch - with --no-track, complete only local branch names' '
|
|
|
|
|
|
test_completion "git switch --no-track " <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:36 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:36 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:36 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git switch - with -c, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git switch -c new-branch " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git switch - with -C, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git switch -C new-branch " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git switch - with -c and --track, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git switch -c new-branch --track " <<-EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git switch - with -C and --track, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git switch -C new-branch --track " <<-EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git switch - with -c and --no-track, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git switch -c new-branch --no-track " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git switch - with -C and --no-track, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git switch -C new-branch --no-track " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - with -b, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git checkout -b new-branch " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - with -B, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git checkout -B new-branch " <<-\EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - with -b and --track, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git checkout -b new-branch --track " <<-EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - with -B and --track, complete all references' '
|
2020-05-28 18:10:37 +00:00
|
|
|
|
test_completion "git checkout -B new-branch --track " <<-EOF
|
|
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:37 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: improve completion for git switch with no options
Add a new --mode option to __git_complete_refs, which allows changing
the behavior to call __git_heads instead of __git_refs.
By passing --mode=heads, __git_complete_refs will only output local
branches. This enables using "--mode=heads --dwim" to enable listing
local branches and the remote unique branch names for DWIM.
Refactor completion support to use the new mode option, rather than
calling __git_heads directly. This has the advantage that we can now
correctly allow local branches along with suitable DWIM refs, rather
than only allowing DWIM when we complete all references.
Choose what mode it uses when calling __git_complete_refs. If -d or
--detach have been provided, then simply complete all refs, but
*without* the DWIM option as these DWIM names won't work properly in
--detach mode.
Otherwise, call __git_complete_refs with the default dwim_opt value and
use the new "heads" mode.
In this way, the basic support for completing just "git switch <TAB>"
will result in only local branches and remote unique names for DWIM.
The basic no-options tests for git switch, as well as several of the
-c/-C tests now pass, so remove the known breakage tags.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 18:10:44 +00:00
|
|
|
|
test_expect_success 'git switch - for -c, complete local branches and unique remote branches' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git switch -c " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: improve completion for git switch with no options
Add a new --mode option to __git_complete_refs, which allows changing
the behavior to call __git_heads instead of __git_refs.
By passing --mode=heads, __git_complete_refs will only output local
branches. This enables using "--mode=heads --dwim" to enable listing
local branches and the remote unique branch names for DWIM.
Refactor completion support to use the new mode option, rather than
calling __git_heads directly. This has the advantage that we can now
correctly allow local branches along with suitable DWIM refs, rather
than only allowing DWIM when we complete all references.
Choose what mode it uses when calling __git_complete_refs. If -d or
--detach have been provided, then simply complete all refs, but
*without* the DWIM option as these DWIM names won't work properly in
--detach mode.
Otherwise, call __git_complete_refs with the default dwim_opt value and
use the new "heads" mode.
In this way, the basic support for completing just "git switch <TAB>"
will result in only local branches and remote unique names for DWIM.
The basic no-options tests for git switch, as well as several of the
-c/-C tests now pass, so remove the known breakage tags.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 18:10:44 +00:00
|
|
|
|
test_expect_success 'git switch - for -C, complete local branches and unique remote branches' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git switch -C " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - for -b, complete local branches and unique remote branches' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git checkout -b " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - for -B, complete local branches and unique remote branches' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git checkout -B " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - for -b with --no-guess, complete local branches only' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git checkout --no-guess -b " <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - for -B with --no-guess, complete local branches only' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git checkout --no-guess -B " <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - for -b with --no-track, complete local branches only' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git checkout --no-track -b " <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:47 +00:00
|
|
|
|
test_expect_success 'git checkout - for -B with --no-track, complete local branches only' '
|
2020-05-28 18:10:38 +00:00
|
|
|
|
test_completion "git checkout --no-track -B " <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:38 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: improve completion for git switch with no options
Add a new --mode option to __git_complete_refs, which allows changing
the behavior to call __git_heads instead of __git_refs.
By passing --mode=heads, __git_complete_refs will only output local
branches. This enables using "--mode=heads --dwim" to enable listing
local branches and the remote unique branch names for DWIM.
Refactor completion support to use the new mode option, rather than
calling __git_heads directly. This has the advantage that we can now
correctly allow local branches along with suitable DWIM refs, rather
than only allowing DWIM when we complete all references.
Choose what mode it uses when calling __git_complete_refs. If -d or
--detach have been provided, then simply complete all refs, but
*without* the DWIM option as these DWIM names won't work properly in
--detach mode.
Otherwise, call __git_complete_refs with the default dwim_opt value and
use the new "heads" mode.
In this way, the basic support for completing just "git switch <TAB>"
will result in only local branches and remote unique names for DWIM.
The basic no-options tests for git switch, as well as several of the
-c/-C tests now pass, so remove the known breakage tags.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28 18:10:44 +00:00
|
|
|
|
test_expect_success 'git switch - with --orphan completes local branch names and unique remote branch names' '
|
2020-05-28 18:10:39 +00:00
|
|
|
|
test_completion "git switch --orphan " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-05-28 18:10:39 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:48 +00:00
|
|
|
|
test_expect_success 'git switch - --orphan with branch already provided completes nothing else' '
|
2020-12-17 01:07:09 +00:00
|
|
|
|
test_completion "git switch --orphan main " <<-\EOF
|
2020-05-28 18:10:39 +00:00
|
|
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:48 +00:00
|
|
|
|
test_expect_success 'git checkout - with --orphan completes local branch names and unique remote branch names' '
|
2020-05-28 18:10:39 +00:00
|
|
|
|
test_completion "git checkout --orphan " <<-\EOF
|
|
|
|
|
|
branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
|
|
|
|
|
main-in-other Z
|
2020-05-28 18:10:39 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-05-28 18:10:48 +00:00
|
|
|
|
test_expect_success 'git checkout - --orphan with branch already provided completes local refs for a start-point' '
|
2020-12-17 01:07:09 +00:00
|
|
|
|
test_completion "git checkout --orphan main " <<-\EOF
|
2020-05-28 18:10:39 +00:00
|
|
|
|
HEAD Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-05-28 18:10:39 +00:00
|
|
|
|
matching-branch Z
|
|
|
|
|
|
matching-tag Z
|
|
|
|
|
|
other/branch-in-other Z
|
2020-12-17 01:07:09 +00:00
|
|
|
|
other/main-in-other Z
|
2020-05-28 18:10:39 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-01-15 10:36:11 +00:00
|
|
|
|
test_expect_success 'git restore completes modified files' '
|
|
|
|
|
|
test_commit A a.file &&
|
|
|
|
|
|
echo B >a.file &&
|
|
|
|
|
|
test_completion "git restore a." <<-\EOF
|
|
|
|
|
|
a.file
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
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 14:17:51 +00: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 13:13:26 +00: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 14:17:51 +00: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
|
2019-11-05 17:07:24 +00:00
|
|
|
|
# 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 14:17:51 +00: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
|
t: factor out FUNNYNAMES as shared lazy prereq
A fair number of tests need to check that the filesystem supports file
names including "funny" characters, like newline, tab, and double-quote.
Jonathan Nieder suggested that this be extracted into a lazy prereq in
the top-level `test-lib.sh`. This patch effects that change.
The FUNNYNAMES prereq now uniformly requires support for newlines, tabs,
and double-quotes in filenames. This very slightly decreases the power
of some tests, which might have run previously on a system that supports
(e.g.) newlines and tabs but not double-quotes, but now will not. This
seems to me like an acceptable tradeoff for consistency.
One test (`t/t9902-completion.sh`) defined FUNNYNAMES to further require
the separators \034 through \037, the test for which was implemented
using the Bash-specific $'\034' syntax. I've elected to leave this one
as is, renaming it to FUNNIERNAMES.
After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has
only one result.
Signed-off-by: William Chargin <wchargin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-06 18:35:08 +00:00
|
|
|
|
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 14:17:51 +00: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ő/Сайн яваарай"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
t: factor out FUNNYNAMES as shared lazy prereq
A fair number of tests need to check that the filesystem supports file
names including "funny" characters, like newline, tab, and double-quote.
Jonathan Nieder suggested that this be extracted into a lazy prereq in
the top-level `test-lib.sh`. This patch effects that change.
The FUNNYNAMES prereq now uniformly requires support for newlines, tabs,
and double-quotes in filenames. This very slightly decreases the power
of some tests, which might have run previously on a system that supports
(e.g.) newlines and tabs but not double-quotes, but now will not. This
seems to me like an acceptable tradeoff for consistency.
One test (`t/t9902-completion.sh`) defined FUNNYNAMES to further require
the separators \034 through \037, the test for which was implemented
using the Bash-specific $'\034' syntax. I've elected to leave this one
as is, renaming it to FUNNIERNAMES.
After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has
only one result.
Signed-off-by: William Chargin <wchargin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-06 18:35:08 +00:00
|
|
|
|
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 14:17:51 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
t: factor out FUNNYNAMES as shared lazy prereq
A fair number of tests need to check that the filesystem supports file
names including "funny" characters, like newline, tab, and double-quote.
Jonathan Nieder suggested that this be extracted into a lazy prereq in
the top-level `test-lib.sh`. This patch effects that change.
The FUNNYNAMES prereq now uniformly requires support for newlines, tabs,
and double-quotes in filenames. This very slightly decreases the power
of some tests, which might have run previously on a system that supports
(e.g.) newlines and tabs but not double-quotes, but now will not. This
seems to me like an acceptable tradeoff for consistency.
One test (`t/t9902-completion.sh`) defined FUNNYNAMES to further require
the separators \034 through \037, the test for which was implemented
using the Bash-specific $'\034' syntax. I've elected to leave this one
as is, renaming it to FUNNIERNAMES.
After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has
only one result.
Signed-off-by: William Chargin <wchargin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-06 18:35:08 +00:00
|
|
|
|
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 14:17:51 +00: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''
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2019-12-19 15:09:16 +00:00
|
|
|
|
test_expect_success '__git_find_on_cmdline - single match' '
|
|
|
|
|
|
echo list >expect &&
|
|
|
|
|
|
(
|
|
|
|
|
|
words=(git command --opt list) &&
|
|
|
|
|
|
cword=${#words[@]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
2019-12-19 15:09:16 +00:00
|
|
|
|
__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[@]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
2019-12-19 15:09:16 +00:00
|
|
|
|
__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[@]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
2019-12-19 15:09:16 +00:00
|
|
|
|
__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 14:17:51 +00:00
|
|
|
|
|
2019-12-19 15:09:18 +00:00
|
|
|
|
test_expect_success '__git_find_on_cmdline - single match with index' '
|
|
|
|
|
|
echo "3 list" >expect &&
|
|
|
|
|
|
(
|
|
|
|
|
|
words=(git command --opt list) &&
|
|
|
|
|
|
cword=${#words[@]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
2019-12-19 15:09:18 +00:00
|
|
|
|
__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[@]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
2019-12-19 15:09:18 +00:00
|
|
|
|
__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[@]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
2019-12-19 15:09:18 +00:00
|
|
|
|
__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 14:17:51 +00:00
|
|
|
|
|
2021-04-22 10:00:51 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2015-05-10 12:50:18 +00:00
|
|
|
|
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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2015-05-10 12:50:17 +00:00
|
|
|
|
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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2012-04-11 21:57:03 +00:00
|
|
|
|
test_expect_success 'basic' '
|
2013-04-10 06:57:51 +00:00
|
|
|
|
run_completion "git " &&
|
2012-04-11 21:57:03 +00:00
|
|
|
|
# built-in
|
|
|
|
|
|
grep -q "^add \$" out &&
|
|
|
|
|
|
# script
|
2019-09-04 22:32:39 +00:00
|
|
|
|
grep -q "^rebase \$" out &&
|
2012-04-11 21:57:03 +00:00
|
|
|
|
# plumbing
|
|
|
|
|
|
! grep -q "^ls-files \$" out &&
|
|
|
|
|
|
|
2019-09-04 22:32:39 +00:00
|
|
|
|
run_completion "git r" &&
|
|
|
|
|
|
! grep -q -v "^r" out
|
2012-04-11 21:57:03 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'double dash "git" itself' '
|
2012-11-11 14:35:56 +00:00
|
|
|
|
test_completion "git --" <<-\EOF
|
2012-04-11 21:57:03 +00:00
|
|
|
|
--paginate Z
|
|
|
|
|
|
--no-pager Z
|
|
|
|
|
|
--git-dir=
|
|
|
|
|
|
--bare Z
|
|
|
|
|
|
--version Z
|
|
|
|
|
|
--exec-path Z
|
2012-04-15 19:44:19 +00:00
|
|
|
|
--exec-path=
|
2012-04-11 21:57:03 +00:00
|
|
|
|
--html-path Z
|
2013-06-22 11:25:18 +00:00
|
|
|
|
--man-path Z
|
2012-04-15 19:44:18 +00:00
|
|
|
|
--info-path Z
|
2012-04-11 21:57:03 +00:00
|
|
|
|
--work-tree=
|
|
|
|
|
|
--namespace=
|
2012-04-15 19:44:18 +00:00
|
|
|
|
--no-replace-objects Z
|
2012-04-11 21:57:03 +00:00
|
|
|
|
--help Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'double dash "git checkout"' '
|
2012-11-11 14:35:56 +00:00
|
|
|
|
test_completion "git checkout --" <<-\EOF
|
2012-04-11 21:57:03 +00:00
|
|
|
|
--quiet Z
|
2018-02-09 11:01:48 +00:00
|
|
|
|
--detach Z
|
|
|
|
|
|
--track Z
|
|
|
|
|
|
--orphan=Z
|
2012-04-11 21:57:03 +00:00
|
|
|
|
--ours Z
|
|
|
|
|
|
--theirs Z
|
|
|
|
|
|
--merge Z
|
2018-02-09 11:01:48 +00:00
|
|
|
|
--conflict=Z
|
2012-04-11 21:57:03 +00:00
|
|
|
|
--patch Z
|
2017-10-24 13:19:31 +00:00
|
|
|
|
--ignore-skip-worktree-bits Z
|
2018-02-09 11:01:48 +00:00
|
|
|
|
--ignore-other-worktrees Z
|
2017-10-24 13:19:31 +00:00
|
|
|
|
--recurse-submodules Z
|
2018-02-09 11:01:48 +00:00
|
|
|
|
--progress Z
|
2018-11-13 17:52:26 +00:00
|
|
|
|
--guess Z
|
|
|
|
|
|
--no-guess Z
|
2018-06-06 09:41:39 +00:00
|
|
|
|
--no-... Z
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
|
--overlay Z
|
2019-12-03 14:02:18 +00:00
|
|
|
|
--pathspec-file-nul Z
|
|
|
|
|
|
--pathspec-from-file=Z
|
2012-04-11 21:57:03 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2012-04-15 19:44:18 +00:00
|
|
|
|
test_expect_success 'general options' '
|
|
|
|
|
|
test_completion "git --ver" "--version " &&
|
|
|
|
|
|
test_completion "git --hel" "--help " &&
|
2012-11-11 14:35:56 +00:00
|
|
|
|
test_completion "git --exe" <<-\EOF &&
|
2012-04-15 19:44:19 +00:00
|
|
|
|
--exec-path Z
|
|
|
|
|
|
--exec-path=
|
|
|
|
|
|
EOF
|
2012-04-15 19:44:18 +00:00
|
|
|
|
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 19:44:20 +00: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 02:48:22 +00: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 19:44:20 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
2013-01-24 23:08:37 +00:00
|
|
|
|
test_expect_success 'git --help completion' '
|
|
|
|
|
|
test_completion "git --help ad" "add " &&
|
|
|
|
|
|
test_completion "git --help core" "core-tutorial "
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2019-03-20 18:03:28 +00:00
|
|
|
|
test_expect_success 'completion.commands removes multiple commands' '
|
2019-03-20 18:03:27 +00:00
|
|
|
|
test_config completion.commands "-cherry -mergetool" &&
|
|
|
|
|
|
git --list-cmds=list-mainporcelain,list-complete,config >out &&
|
|
|
|
|
|
! grep -E "^(cherry|mergetool)$" out
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion tests: add tests for the __git_refs() helper function
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for 'git checkout's tracking DWIMery,
- not in a git repository, and
- interesting combinations of the above.
Seven of these tests expect failure, mostly demonstrating bugs related
to listing refs from a remote repository:
- ignoring the repository specified on the command line (2 tests),
- listing refs from the wrong place when the name of a configured
remote happens to match a directory,
- listing only 'HEAD' but no short refs from a remote given as URL,
- listing 'HEAD' even from non-existing remotes (2 tests), and
- listing 'HEAD' when not in a repository.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03 02:48:14 +00:00
|
|
|
|
test_expect_success 'setup for integration tests' '
|
2012-09-26 21:47:51 +00:00
|
|
|
|
echo content >file1 &&
|
|
|
|
|
|
echo more >file2 &&
|
2017-02-03 02:48:10 +00:00
|
|
|
|
git add file1 file2 &&
|
2012-09-26 21:47:51 +00:00
|
|
|
|
git commit -m one &&
|
|
|
|
|
|
git branch mybranch &&
|
|
|
|
|
|
git tag mytag
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'checkout completes ref names' '
|
2012-11-11 14:35:56 +00:00
|
|
|
|
test_completion "git checkout m" <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2012-11-11 14:35:54 +00:00
|
|
|
|
mybranch Z
|
|
|
|
|
|
mytag Z
|
2012-09-26 21:47:51 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2022-11-21 00:26:58 +00:00
|
|
|
|
test_expect_success 'checkout does not match ref names of a different case' '
|
|
|
|
|
|
test_completion "git checkout M" ""
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'checkout matches case insensitively with GIT_COMPLETION_IGNORE_CASE' '
|
|
|
|
|
|
(
|
|
|
|
|
|
GIT_COMPLETION_IGNORE_CASE=1 &&
|
|
|
|
|
|
test_completion "git checkout M" <<-\EOF
|
|
|
|
|
|
main Z
|
|
|
|
|
|
mybranch Z
|
|
|
|
|
|
mytag Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2022-11-21 00:26:59 +00:00
|
|
|
|
test_expect_success 'checkout completes pseudo refs' '
|
|
|
|
|
|
test_completion "git checkout H" <<-\EOF
|
|
|
|
|
|
HEAD Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'checkout completes pseudo refs case insensitively with GIT_COMPLETION_IGNORE_CASE' '
|
|
|
|
|
|
(
|
|
|
|
|
|
GIT_COMPLETION_IGNORE_CASE=1 &&
|
|
|
|
|
|
test_completion "git checkout h" <<-\EOF
|
|
|
|
|
|
HEAD 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 02:48:24 +00: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
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2012-09-26 21:47:51 +00:00
|
|
|
|
test_expect_success 'show completes all refs' '
|
2012-11-11 14:35:56 +00:00
|
|
|
|
test_completion "git show m" <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2012-11-11 14:35:54 +00:00
|
|
|
|
mybranch Z
|
|
|
|
|
|
mytag Z
|
2012-09-26 21:47:51 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success '<ref>: completes paths' '
|
2012-11-11 14:35:56 +00:00
|
|
|
|
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 14:05:09 +00:00
|
|
|
|
file1Z
|
|
|
|
|
|
file2Z
|
2012-09-26 21:47:51 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2012-09-26 21:51:06 +00:00
|
|
|
|
test_expect_success 'complete tree filename with spaces' '
|
|
|
|
|
|
echo content >"name with spaces" &&
|
2017-02-03 02:48:10 +00:00
|
|
|
|
git add "name with spaces" &&
|
2012-09-26 21:51:06 +00:00
|
|
|
|
git commit -m spaces &&
|
2012-11-11 14:35:56 +00:00
|
|
|
|
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 14:05:09 +00:00
|
|
|
|
name with spacesZ
|
2012-09-26 21:51:06 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2013-04-10 06:57:55 +00:00
|
|
|
|
test_expect_success 'complete tree filename with metacharacters' '
|
2012-09-26 21:51:06 +00:00
|
|
|
|
echo content >"name with \${meta}" &&
|
2017-02-03 02:48:10 +00:00
|
|
|
|
git add "name with \${meta}" &&
|
2012-09-26 21:51:06 +00:00
|
|
|
|
git commit -m meta &&
|
2012-11-11 14:35:56 +00:00
|
|
|
|
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 14:05:09 +00:00
|
|
|
|
name with ${meta}Z
|
|
|
|
|
|
name with spacesZ
|
2012-09-26 21:51:06 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2018-12-13 14:04:19 +00:00
|
|
|
|
test_expect_success PERL 'send-email' '
|
2019-10-15 09:06:40 +00:00
|
|
|
|
test_completion "git send-email --cov" <<-\EOF &&
|
|
|
|
|
|
--cover-from-description=Z
|
|
|
|
|
|
--cover-letter Z
|
|
|
|
|
|
EOF
|
2021-10-25 21:27:06 +00:00
|
|
|
|
test_completion "git send-email --val" <<-\EOF &&
|
|
|
|
|
|
--validate Z
|
|
|
|
|
|
EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
test_completion "git send-email ma" "main "
|
2012-10-16 00:21:50 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
2013-04-27 20:09:59 +00:00
|
|
|
|
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-16 22:41:12 +00:00
|
|
|
|
echo "out_sorted" >> .gitignore &&
|
2013-04-27 20:09:59 +00:00
|
|
|
|
|
|
|
|
|
|
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 04:17:46 +00:00
|
|
|
|
mkdir -p some/deep &&
|
|
|
|
|
|
touch some/deep/path &&
|
|
|
|
|
|
test_completion "git add some/" "some/deep" &&
|
|
|
|
|
|
git clean -f some &&
|
|
|
|
|
|
|
2013-04-27 20:09:59 +00:00
|
|
|
|
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 &&
|
2015-03-20 10:06:15 +00:00
|
|
|
|
test_completion "git ls-files " <<-\EOF &&
|
2013-04-27 20:09:59 +00:00
|
|
|
|
.gitignore
|
|
|
|
|
|
dir
|
|
|
|
|
|
modified
|
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
|
|
touch momified &&
|
|
|
|
|
|
test_completion "git add mom" "momified"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2020-11-10 02:03:42 +00:00
|
|
|
|
test_expect_success "simple alias" '
|
|
|
|
|
|
test_config alias.co checkout &&
|
|
|
|
|
|
test_completion "git co m" <<-\EOF
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-11-10 02:03:42 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2020-11-10 02:03:42 +00:00
|
|
|
|
mybranch Z
|
|
|
|
|
|
mytag Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2014-06-12 18:49:29 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2014-06-12 18:49:29 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2014-06-12 18:49:29 +00:00
|
|
|
|
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
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main Z
|
2014-06-12 18:49:29 +00:00
|
|
|
|
mybranch Z
|
|
|
|
|
|
mytag Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2023-09-20 18:28:22 +00:00
|
|
|
|
test_expect_success 'completion used <cmd> completion for alias: !f() { : <cmd> ; ... }' '
|
|
|
|
|
|
test_config alias.co "!f() { : checkout ; if ... } f" &&
|
|
|
|
|
|
test_completion "git co m" <<-\EOF
|
|
|
|
|
|
main Z
|
|
|
|
|
|
mybranch Z
|
|
|
|
|
|
mytag Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'completion used <cmd> completion for alias: !f() { : <cmd>; ... }' '
|
|
|
|
|
|
test_config alias.co "!f() { : checkout; if ... } f" &&
|
|
|
|
|
|
test_completion "git co m" <<-\EOF
|
|
|
|
|
|
main Z
|
|
|
|
|
|
mybranch Z
|
|
|
|
|
|
mytag Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2018-03-24 20:35:22 +00:00
|
|
|
|
test_expect_success 'completion without explicit _git_xxx function' '
|
|
|
|
|
|
test_completion "git version --" <<-\EOF
|
|
|
|
|
|
--build-options Z
|
2018-05-27 08:38:26 +00:00
|
|
|
|
--no-build-options Z
|
2018-03-24 20:35:22 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2013-04-27 20:10:00 +00:00
|
|
|
|
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"
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: expand "push --delete <remote> <ref>" for refs on that <remote>
Change the completion of "push --delete <remote> <ref>" to complete
refs on that <remote>, not all refs.
Before this cloning git.git and doing "git push --delete origin
p<TAB>" will complete nothing, since a fresh clone of git.git will
have no "pu" branch, whereas origin/p<TAB> will uselessly complete
origin/pu, but fully qualified references aren't accepted by
"--delete".
Now p<TAB> will complete as "pu". The completion of giving --delete
later, e.g. "git push origin --delete p<TAB>" remains unchanged, this
is a bug, but is a general existing limitation of the bash completion,
and not how git-push is documented, so I'm not fixing that case, but
adding a failing TODO test for it.
The testing code was supplied by SZEDER Gábor in
<20170421122832.24617-1-szeder.dev@gmail.com> with minor setup
modifications on my part.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
Test-code-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-22 17:55:04 +00:00
|
|
|
|
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 &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other Z
|
completion: expand "push --delete <remote> <ref>" for refs on that <remote>
Change the completion of "push --delete <remote> <ref>" to complete
refs on that <remote>, not all refs.
Before this cloning git.git and doing "git push --delete origin
p<TAB>" will complete nothing, since a fresh clone of git.git will
have no "pu" branch, whereas origin/p<TAB> will uselessly complete
origin/pu, but fully qualified references aren't accepted by
"--delete".
Now p<TAB> will complete as "pu". The completion of giving --delete
later, e.g. "git push origin --delete p<TAB>" remains unchanged, this
is a bug, but is a general existing limitation of the bash completion,
and not how git-push is documented, so I'm not fixing that case, but
adding a failing TODO test for it.
The testing code was supplied by SZEDER Gábor in
<20170421122832.24617-1-szeder.dev@gmail.com> with minor setup
modifications on my part.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
Test-code-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-22 17:55:04 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
words=(git push '$flag' other ma) &&
|
|
|
|
|
|
cword=${#words[@]} cur=${words[cword-1]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
completion: expand "push --delete <remote> <ref>" for refs on that <remote>
Change the completion of "push --delete <remote> <ref>" to complete
refs on that <remote>, not all refs.
Before this cloning git.git and doing "git push --delete origin
p<TAB>" will complete nothing, since a fresh clone of git.git will
have no "pu" branch, whereas origin/p<TAB> will uselessly complete
origin/pu, but fully qualified references aren't accepted by
"--delete".
Now p<TAB> will complete as "pu". The completion of giving --delete
later, e.g. "git push origin --delete p<TAB>" remains unchanged, this
is a bug, but is a general existing limitation of the bash completion,
and not how git-push is documented, so I'm not fixing that case, but
adding a failing TODO test for it.
The testing code was supplied by SZEDER Gábor in
<20170421122832.24617-1-szeder.dev@gmail.com> with minor setup
modifications on my part.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
Test-code-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-22 17:55:04 +00:00
|
|
|
|
__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 &&
|
2020-12-17 01:07:09 +00:00
|
|
|
|
main-in-other Z
|
completion: expand "push --delete <remote> <ref>" for refs on that <remote>
Change the completion of "push --delete <remote> <ref>" to complete
refs on that <remote>, not all refs.
Before this cloning git.git and doing "git push --delete origin
p<TAB>" will complete nothing, since a fresh clone of git.git will
have no "pu" branch, whereas origin/p<TAB> will uselessly complete
origin/pu, but fully qualified references aren't accepted by
"--delete".
Now p<TAB> will complete as "pu". The completion of giving --delete
later, e.g. "git push origin --delete p<TAB>" remains unchanged, this
is a bug, but is a general existing limitation of the bash completion,
and not how git-push is documented, so I'm not fixing that case, but
adding a failing TODO test for it.
The testing code was supplied by SZEDER Gábor in
<20170421122832.24617-1-szeder.dev@gmail.com> with minor setup
modifications on my part.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
Test-code-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-22 17:55:04 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
(
|
|
|
|
|
|
words=(git push other '$flag' ma) &&
|
|
|
|
|
|
cword=${#words[@]} cur=${words[cword-1]} &&
|
2021-04-22 10:00:51 +00:00
|
|
|
|
__git_cmd_idx=1 &&
|
completion: expand "push --delete <remote> <ref>" for refs on that <remote>
Change the completion of "push --delete <remote> <ref>" to complete
refs on that <remote>, not all refs.
Before this cloning git.git and doing "git push --delete origin
p<TAB>" will complete nothing, since a fresh clone of git.git will
have no "pu" branch, whereas origin/p<TAB> will uselessly complete
origin/pu, but fully qualified references aren't accepted by
"--delete".
Now p<TAB> will complete as "pu". The completion of giving --delete
later, e.g. "git push origin --delete p<TAB>" remains unchanged, this
is a bug, but is a general existing limitation of the bash completion,
and not how git-push is documented, so I'm not fixing that case, but
adding a failing TODO test for it.
The testing code was supplied by SZEDER Gábor in
<20170421122832.24617-1-szeder.dev@gmail.com> with minor setup
modifications on my part.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
Test-code-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-22 17:55:04 +00:00
|
|
|
|
__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 12:26:45 +00:00
|
|
|
|
test_expect_success 'git config - section' '
|
completion: add tests for 'git config' completion
The next patches will change/refactor the way we complete
configuration variable names and values, so add a few tests to cover
the basics, namely the completion of matching configuration sections,
full variable names, and their values.
Note that the test checking the completion of configuration sections
is currently failing, though it's not a sign of an actual bug. If a
section contains multiple variables, then that section is currently
repeated as many times as the number of variables in there. This is
not a correctness issue in practice, because Bash's completion
facilities remove all repetitions anyway. Consequently, we could list
all those repeated sections in the expected output of this test as
well, but then it would have to be updated whenever a new
configuration variable is added to those sections. Instead, list each
matching configuration section only once, mark the test as failing for
now, and the next patch will update the completion script to avoid
those repetitions.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13 12:26:44 +00:00
|
|
|
|
test_completion "git config br" <<-\EOF
|
|
|
|
|
|
branch.Z
|
|
|
|
|
|
browser.Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2022-07-16 20:13:43 +00:00
|
|
|
|
test_expect_success 'git config - section include, includeIf' '
|
|
|
|
|
|
test_completion "git config inclu" <<-\EOF
|
|
|
|
|
|
include.Z
|
|
|
|
|
|
includeIf.Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: add tests for 'git config' completion
The next patches will change/refactor the way we complete
configuration variable names and values, so add a few tests to cover
the basics, namely the completion of matching configuration sections,
full variable names, and their values.
Note that the test checking the completion of configuration sections
is currently failing, though it's not a sign of an actual bug. If a
section contains multiple variables, then that section is currently
repeated as many times as the number of variables in there. This is
not a correctness issue in practice, because Bash's completion
facilities remove all repetitions anyway. Consequently, we could list
all those repeated sections in the expected output of this test as
well, but then it would have to be updated whenever a new
configuration variable is added to those sections. Instead, list each
matching configuration section only once, mark the test as failing for
now, and the next patch will update the completion script to avoid
those repetitions.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13 12:26:44 +00:00
|
|
|
|
test_expect_success 'git config - variable name' '
|
|
|
|
|
|
test_completion "git config log.d" <<-\EOF
|
|
|
|
|
|
log.date Z
|
|
|
|
|
|
log.decorate Z
|
2021-04-13 11:41:17 +00:00
|
|
|
|
log.diffMerges Z
|
completion: add tests for 'git config' completion
The next patches will change/refactor the way we complete
configuration variable names and values, so add a few tests to cover
the basics, namely the completion of matching configuration sections,
full variable names, and their values.
Note that the test checking the completion of configuration sections
is currently failing, though it's not a sign of an actual bug. If a
section contains multiple variables, then that section is currently
repeated as many times as the number of variables in there. This is
not a correctness issue in practice, because Bash's completion
facilities remove all repetitions anyway. Consequently, we could list
all those repeated sections in the expected output of this test as
well, but then it would have to be updated whenever a new
configuration variable is added to those sections. Instead, list each
matching configuration section only once, mark the test as failing for
now, and the next patch will update the completion script to avoid
those repetitions.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13 12:26:44 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2022-07-16 20:13:43 +00:00
|
|
|
|
test_expect_success 'git config - variable name include' '
|
|
|
|
|
|
test_completion "git config include.p" <<-\EOF
|
|
|
|
|
|
include.path Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-02-10 18:32:21 +00:00
|
|
|
|
test_expect_success 'setup for git config submodule tests' '
|
|
|
|
|
|
test_create_repo sub &&
|
|
|
|
|
|
test_commit -C sub initial &&
|
|
|
|
|
|
git submodule add ./sub
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: add and use __git_compute_first_level_config_vars_for_section
The function __git_complete_config_variable_name in the Bash completion
script hardcodes several config variable names. These variables are
those in config sections where user-defined names can appear, such as
"branch.<name>". These sections are treated first by the case statement,
and the two last "catch all" cases are used for other sections, making
use of the __git_compute_config_vars and __git_compute_config_sections
function, which omit listing any variables containing wildcards or
placeholders. Having hardcoded config variables introduces the risk of
the completion code becoming out of sync with the actual config
variables accepted by Git.
To avoid these hardcoded config variables, introduce a new function,
__git_compute_first_level_config_vars_for_section, making use of the
existing __git_config_vars variable. This function takes as argument a
config section name and computes the matching "first level" config
variables for that section, i.e. those _not_ containing any placeholder,
like 'branch.autoSetupMerge, 'remote.pushDefault', etc. Use this
function and the variables it defines in the 'branch.*', 'remote.*' and
'submodule.*' switches of the case statement instead of hardcoding the
corresponding config variables. Note that we use indirect expansion to
create a variable for each section, instead of using a single
associative array indexed by section names, because associative arrays
are not supported in Bash 3, on which macOS is stuck for licensing
reasons.
Use the existing pattern in the completion script of using global
variables to cache the list of config variables for each section. The
rationale for such caching is explained in eaa4e6ee2a (Speed up bash
completion loading, 2009-11-17), and the current approach to using and
defining them via 'test -n' is explained in cf0ff02a38 (completion: work
around zsh option propagation bug, 2012-02-02).
Adjust the name of one of the tests added in the previous commit,
reflecting that it now also tests the new function.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-10 18:32:22 +00:00
|
|
|
|
test_expect_success 'git config - variable name - submodule and __git_compute_first_level_config_vars_for_section' '
|
2024-02-10 18:32:21 +00:00
|
|
|
|
test_completion "git config submodule." <<-\EOF
|
|
|
|
|
|
submodule.active Z
|
|
|
|
|
|
submodule.alternateErrorStrategy Z
|
|
|
|
|
|
submodule.alternateLocation Z
|
|
|
|
|
|
submodule.fetchJobs Z
|
|
|
|
|
|
submodule.propagateBranches Z
|
|
|
|
|
|
submodule.recurse Z
|
|
|
|
|
|
submodule.sub.Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: add and use __git_compute_second_level_config_vars_for_section
In a previous commit we removed some hardcoded config variable names from
function __git_complete_config_variable_name in the completion script by
introducing a new function,
__git_compute_first_level_config_vars_for_section.
The remaining hardcoded config variables are "second level"
configuration variables, meaning 'branch.<name>.upstream',
'remote.<name>.url', etc. where <name> is a user-defined name.
Making use of the new existing --config flag to 'git help', add a new
function, __git_compute_second_level_config_vars_for_section. This
function takes as argument a config section name and computes the
corresponding second-level config variables, i.e. those that contain a
'<' which indicates the start of a placeholder. Note that as in
__git_compute_first_level_config_vars_for_section added previsouly, we
use indirect expansion instead of associative arrays to stay compatible
with Bash 3 on which macOS is stuck for licensing reasons.
As explained in the previous commit, we use the existing pattern in the
completion script of using global variables to cache the list of
variables for each section.
Use this new function and the variables it defines in
__git_complete_config_variable_name to remove hardcoded config
variables, and add a test to verify the new function. Use a single
'case' for all sections with second-level variables names, since the
code for each of them is now exactly the same.
Adjust the name of a test added in a previous commit to reflect that it
now tests the added function.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-10 18:32:23 +00:00
|
|
|
|
test_expect_success 'git config - variable name - __git_compute_second_level_config_vars_for_section' '
|
2024-02-10 18:32:21 +00:00
|
|
|
|
test_completion "git config submodule.sub." <<-\EOF
|
|
|
|
|
|
submodule.sub.url Z
|
|
|
|
|
|
submodule.sub.update Z
|
|
|
|
|
|
submodule.sub.branch Z
|
|
|
|
|
|
submodule.sub.fetchRecurseSubmodules Z
|
|
|
|
|
|
submodule.sub.ignore Z
|
|
|
|
|
|
submodule.sub.active Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: add tests for 'git config' completion
The next patches will change/refactor the way we complete
configuration variable names and values, so add a few tests to cover
the basics, namely the completion of matching configuration sections,
full variable names, and their values.
Note that the test checking the completion of configuration sections
is currently failing, though it's not a sign of an actual bug. If a
section contains multiple variables, then that section is currently
repeated as many times as the number of variables in there. This is
not a correctness issue in practice, because Bash's completion
facilities remove all repetitions anyway. Consequently, we could list
all those repeated sections in the expected output of this test as
well, but then it would have to be updated whenever a new
configuration variable is added to those sections. Instead, list each
matching configuration section only once, mark the test as failing for
now, and the next patch will update the completion script to avoid
those repetitions.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13 12:26:44 +00:00
|
|
|
|
test_expect_success 'git config - value' '
|
|
|
|
|
|
test_completion "git config color.pager " <<-\EOF
|
|
|
|
|
|
false Z
|
|
|
|
|
|
true Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
completion: complete configuration sections and variable names for 'git -c'
'git config' expects a configuration variable's name and value in
separate arguments, so we let the __gitcomp() helper append a space
character to each variable name by default, like we do for most other
things (--options, refs, paths, etc.). 'git -c', however, expects
them in a single option joined by a '=' character, i.e.
'section.name=value', so we should append a '=' character to each
fully completed variable name, but no space, so the user can continue
typing the value right away.
Add an option to the __git_complete_config_variable_name() function to
allow callers to specify an alternate suffix to add, and use it to
append that '=' character to configuration variables. Update the
__gitcomp() helper function to not append a trailing space to any
completion words ending with a '=', not just to those option with a
stuck argument.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13 12:26:49 +00:00
|
|
|
|
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
|
2021-04-13 11:41:17 +00:00
|
|
|
|
log.diffMerges=Z
|
completion: complete configuration sections and variable names for 'git -c'
'git config' expects a configuration variable's name and value in
separate arguments, so we let the __gitcomp() helper append a space
character to each variable name by default, like we do for most other
things (--options, refs, paths, etc.). 'git -c', however, expects
them in a single option joined by a '=' character, i.e.
'section.name=value', so we should append a '=' character to each
fully completed variable name, but no space, so the user can continue
typing the value right away.
Add an option to the __git_complete_config_variable_name() function to
allow callers to specify an alternate suffix to add, and use it to
append that '=' character to configuration variables. Update the
__gitcomp() helper function to not append a trailing space to any
completion words ending with a '=', not just to those option with a
stuck argument.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13 12:26:49 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2019-08-13 12:26:50 +00:00
|
|
|
|
test_expect_success 'git -c - value' '
|
|
|
|
|
|
test_completion "git -c color.pager=" <<-\EOF
|
2019-08-13 12:26:52 +00:00
|
|
|
|
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
|
2021-04-13 11:41:17 +00:00
|
|
|
|
log.diffMerges=Z
|
2019-08-13 12:26:52 +00:00
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git clone --config= - value' '
|
|
|
|
|
|
test_completion "git clone --config=color.pager=" <<-\EOF
|
2019-08-13 12:26:50 +00:00
|
|
|
|
false Z
|
|
|
|
|
|
true Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2024-03-02 14:37:34 +00:00
|
|
|
|
test_expect_success 'git reflog show' '
|
|
|
|
|
|
test_when_finished "git checkout - && git branch -d shown" &&
|
|
|
|
|
|
git checkout -b shown &&
|
|
|
|
|
|
test_completion "git reflog sho" <<-\EOF &&
|
|
|
|
|
|
show Z
|
|
|
|
|
|
shown Z
|
|
|
|
|
|
EOF
|
|
|
|
|
|
test_completion "git reflog show sho" "shown " &&
|
2024-03-02 15:50:47 +00:00
|
|
|
|
test_completion "git reflog shown sho" "shown " &&
|
|
|
|
|
|
test_completion "git reflog --unt" "--until=" &&
|
|
|
|
|
|
test_completion "git reflog show --unt" "--until=" &&
|
|
|
|
|
|
test_completion "git reflog shown --unt" "--until="
|
2024-03-02 14:37:34 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
2021-08-16 09:10:23 +00:00
|
|
|
|
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 14:16:04 +00:00
|
|
|
|
test_expect_success 'sourcing the completion script clears cached commands' '
|
2022-02-02 11:15:09 +00:00
|
|
|
|
(
|
|
|
|
|
|
__git_compute_all_commands &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test -n "$__git_all_commands" &&
|
2022-02-02 11:15:09 +00:00
|
|
|
|
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test -z "$__git_all_commands"
|
2022-02-02 11:15:09 +00:00
|
|
|
|
)
|
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 14:16:04 +00: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 21:15:29 +00:00
|
|
|
|
test_expect_success 'sourcing the completion script clears cached merge strategies' '
|
2022-02-02 11:15:09 +00:00
|
|
|
|
(
|
|
|
|
|
|
__git_compute_merge_strategies &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test -n "$__git_merge_strategies" &&
|
2022-02-02 11:15:09 +00:00
|
|
|
|
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test -z "$__git_merge_strategies"
|
2022-02-02 11:15:09 +00:00
|
|
|
|
)
|
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 14:16:04 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'sourcing the completion script clears cached --options' '
|
2022-02-02 11:15:09 +00:00
|
|
|
|
(
|
|
|
|
|
|
__gitcomp_builtin checkout &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test -n "$__gitcomp_builtin_checkout" &&
|
2022-02-02 11:15:09 +00:00
|
|
|
|
__gitcomp_builtin notes_edit &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test -n "$__gitcomp_builtin_notes_edit" &&
|
2022-02-02 11:15:09 +00:00
|
|
|
|
. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
|
t: drop "verbose" helper function
We have a small helper function called "verbose", with the idea that you
can write:
verbose foo
to get a message to stderr when the "foo" command fails, even if it does
not produce any output itself. This goes back to 8ad1652418 (t5304: use
helper to report failure of "test foo = bar", 2014-10-10). It does work,
but overall it has not been a big success for two reasons:
1. Test writers have to remember to put it there (and the resulting
test code is longer as a result).
2. It doesn't handle the opposite case (we expect "foo" to fail, but
it succeeds), leading to inconsistencies in tests (which you can
see in many hunks of this patch, e.g. ones involving "has_cr").
Most importantly, we added a136f6d8ff (test-lib.sh: support -x option
for shell-tracing, 2014-10-10) at the same time, and it does roughly the
same thing. The output is not quite as succinct as "verbose", and you
have to watch out for stray shell-traces ending up in stderr. But it
solves both of the problems above, and has clearly become the preferred
tool.
Let's consider the "verbose" function a failed experiment and remove the
last few callers (which are all many years old, and have been dwindling
as we remove them from scripts we touch for other reasons). It will be
one less thing for new test writers to see and wonder if they should be
using themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-08 19:04:57 +00:00
|
|
|
|
test -z "$__gitcomp_builtin_checkout" &&
|
|
|
|
|
|
test -z "$__gitcomp_builtin_notes_edit"
|
2022-02-02 11:15:09 +00:00
|
|
|
|
)
|
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 14:16:04 +00: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 01:55:43 +00: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' '
|
2022-02-02 11:15:09 +00:00
|
|
|
|
(
|
|
|
|
|
|
. "$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 01:55:43 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
completion: add a GIT_COMPLETION_SHOW_ALL_COMMANDS
Add a GIT_COMPLETION_SHOW_ALL_COMMANDS=1 configuration setting to go
with the existing GIT_COMPLETION_SHOW_ALL=1 added in
c099f579b98 (completion: add GIT_COMPLETION_SHOW_ALL env var,
2020-08-19).
This will include plumbing commands such as "cat-file" in "git <TAB>"
and "git c<TAB>" completion. Without/with this I have 134 and 243
completion with git <TAB>, respectively.
It was already possible to do this by tweaking
GIT_TESTING_PORCELAIN_COMMAND_LIST= from the outside, that testing
variable was added in 84a97131065 (completion: let git provide the
completable command list, 2018-05-20). Doing this before loading
git-completion.bash worked:
export GIT_TESTING_PORCELAIN_COMMAND_LIST="$(git --list-cmds=builtins,main,list-mainporcelain,others,nohelpers,alias,list-complete,config)"
But such testing variables are not meant to be used from the outside,
and we make no guarantees that those internal won't change. So let's
expose this as a dedicated configuration knob.
It would be better to teach --list-cmds=* a new category which would
include all of these groups, but that's a larger change that we can
leave for some other time.
1. https://lore.kernel.org/git/CAGP6POJ9gwp+t-eP3TPkivBLLbNb2+qj=61Mehcj=1BgrVOSLA@mail.gmail.com/
Reported-by: Hongyi Zhao <hongyi.zhao@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-02 11:15:10 +00: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 01:55:43 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
2020-12-30 23:29:49 +00:00
|
|
|
|
test_expect_success '__git_complete' '
|
|
|
|
|
|
unset -f __git_wrap__git_main &&
|
2020-12-30 23:29:50 +00:00
|
|
|
|
|
2020-12-30 23:29:49 +00:00
|
|
|
|
__git_complete foo __git_main &&
|
|
|
|
|
|
__git_have_func __git_wrap__git_main &&
|
2020-12-30 23:29:50 +00:00
|
|
|
|
unset -f __git_wrap__git_main &&
|
|
|
|
|
|
|
2020-12-30 23:29:49 +00:00
|
|
|
|
__git_complete gf _git_fetch &&
|
2020-12-30 23:29:50 +00:00
|
|
|
|
__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
|
2020-12-30 23:29:49 +00:00
|
|
|
|
'
|
|
|
|
|
|
|
2024-01-15 10:36:11 +00:00
|
|
|
|
test_expect_success '__git_pseudoref_exists' '
|
|
|
|
|
|
test_when_finished "rm -rf repo" &&
|
|
|
|
|
|
git init repo &&
|
|
|
|
|
|
(
|
|
|
|
|
|
cd repo &&
|
|
|
|
|
|
sane_unset __git_repo_path &&
|
|
|
|
|
|
|
2024-01-15 10:36:15 +00:00
|
|
|
|
# HEAD should exist, even if it points to an unborn branch.
|
|
|
|
|
|
__git_pseudoref_exists HEAD >output 2>&1 &&
|
|
|
|
|
|
test_must_be_empty output &&
|
|
|
|
|
|
|
2024-01-15 10:36:11 +00:00
|
|
|
|
# HEAD points to an existing branch, so it should exist.
|
|
|
|
|
|
test_commit A &&
|
|
|
|
|
|
__git_pseudoref_exists HEAD >output 2>&1 &&
|
|
|
|
|
|
test_must_be_empty output &&
|
|
|
|
|
|
|
|
|
|
|
|
# CHERRY_PICK_HEAD does not exist, so the existence check should fail.
|
|
|
|
|
|
! __git_pseudoref_exists CHERRY_PICK_HEAD >output 2>&1 &&
|
|
|
|
|
|
test_must_be_empty output &&
|
|
|
|
|
|
|
|
|
|
|
|
# CHERRY_PICK_HEAD points to a commit, so it should exist.
|
|
|
|
|
|
git update-ref CHERRY_PICK_HEAD A &&
|
|
|
|
|
|
__git_pseudoref_exists CHERRY_PICK_HEAD >output 2>&1 &&
|
|
|
|
|
|
test_must_be_empty output
|
|
|
|
|
|
)
|
|
|
|
|
|
'
|
|
|
|
|
|
|
2012-04-11 21:57:03 +00:00
|
|
|
|
test_done
|