* git log .. autocompletion
@ 2021-08-31 9:22 Linus Kardell
2021-09-01 9:00 ` Oliver Kiddle
0 siblings, 1 reply; 3+ messages in thread
From: Linus Kardell @ 2021-08-31 9:22 UTC (permalink / raw)
To: zsh-workers
[-- Attachment #1.1.1: Type: text/plain, Size: 368 bytes --]
Tab autocompletion does not seem to work for superdirectories for git
log. If you stand in a subdirectory of a git repo, type "git log .." or
"git log ../" and press tab you just get a list of branches (even though
none of them start with ".."), and if type "git log -- .." and press tab
nothing happens at all. This is with zsh 5.8 on openSUSE Tumbleweed.
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 8719 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: git log .. autocompletion
2021-08-31 9:22 git log .. autocompletion Linus Kardell
@ 2021-09-01 9:00 ` Oliver Kiddle
2021-09-01 14:06 ` Daniel Shahaf
0 siblings, 1 reply; 3+ messages in thread
From: Oliver Kiddle @ 2021-09-01 9:00 UTC (permalink / raw)
To: Linus Kardell; +Cc: zsh-workers
Linus Kardell wrote:
> Tab autocompletion does not seem to work for superdirectories for git
> log. If you stand in a subdirectory of a git repo, type "git log .." or
> "git log ../" and press tab you just get a list of branches (even though
> none of them start with ".."), and if type "git log -- .." and press tab
> nothing happens at all. This is with zsh 5.8 on openSUSE Tumbleweed.
This seems to have been broken with the change in 36957/6a3de99.
That change switched to using -r for a recursive listing to allow
things like 'git log S/e<TAB>' to expand to Src/exec.c
This change first strips ../ components but then passes them to git
ls-tree. (We perhaps should also do likewise for ./ components). I've
also made it only add the -r if there's at least one slash in what
remains which is an optimisation on a big repository with no loss of
functionality.
git ls-tree -r @ ..
will list files in the current directory without any directory prefix.
For completion, the effect is similar to the ignore-parents style with
_files (arguably a feature) but may have undesirable effects with
creative use of matching control. Does anyone think we should handle
this properly at the cost of extra complexity?
Oliver
diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index a82b70e83..7c7fb22bc 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -7370,7 +7370,6 @@ __git_changed_files () {
# which case it is relative to the repository root.
(( $+functions[__git_tree_files] )) ||
__git_tree_files () {
- local multi_parts_opts
local tree Path
integer at_least_one_tree_added
local -a tree_files compadd_opts
@@ -7383,11 +7382,12 @@ __git_tree_files () {
zparseopts -D -E -a compadd_opts V+: J+: 1 2 o+: n f x+: X+: M+: P: S: r: R: q F:
- [[ "$1" == */ ]] && Path="$1" || Path="${1:h}/"
+ Path=${(M)1##(../)#}
+ [[ ${1##(../)#} = */* ]] && extra_args+=( -r )
shift
(( at_least_one_tree_added = 0 ))
- for tree in $*; do
- tree_files+=(${(ps:\0:)"$(_call_program tree-files git ls-tree -r ${(q)extra_args} --name-only -z ${(q)tree} 2>/dev/null)"})
+ for tree; do
+ tree_files+=(${(ps:\0:)"$(_call_program tree-files git ls-tree $extra_args --name-only -z ${(q)tree} $Path 2>/dev/null)"})
__git_command_successful $pipestatus && (( at_least_one_tree_added = 1 ))
done
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-09-01 14:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-31 9:22 git log .. autocompletion Linus Kardell
2021-09-01 9:00 ` Oliver Kiddle
2021-09-01 14:06 ` Daniel Shahaf
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).