Re: [PATCH] completion: avoid ls-remote in certain scenarios
On Sun, Jun 2, 2013 at 5:08 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: It's _very_ slow in many cases, and there's really no point in fetching *everything* from the remote just for completion. In many cases it might be faster for the user to type the whole thing. Besides, if I understand the use of __git_refs correctly, it is primarily about completing things like git checkout -b topic origin/TAB where you actively want _local_ copies of what you currently have in refs/remotes/origin/, not what you would get if you were to fetch and then type the command again, so in that sense, using ls-remote is a wrong thing to do in the first place. Yeah, but we wouldn't use ls-remote in those cases, only when __gitdir is not available. Try 'git checkout TAB' outside a git repository. This however may need to be made optional if this is also being used to complete git fetch git://g.k.org/pub/scm/git/git.git/ TAB to list what can be fetched, but I do not think that is a very common thing to do (you either know what you want to fetch, in which case you do not complete but copy paste, or more likely you have a named remote and fetch the whole thing). Indeed. And it doesn't make sense to punish the typical use-cases because of the atypical ones. Besides: git fetch git://g.k.org/pub/scm/git/git.git/ refs/TAB Would still complete everything. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: avoid ls-remote in certain scenarios
Felipe Contreras wrote:
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 1c35eef..2ce4f7d 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -427,14 +427,8 @@ __git_refs ()
done
;;
*)
- git ls-remote $dir HEAD ORIG_HEAD 'refs/tags/*'
'refs/heads/*' 'refs/remotes/*' 2/dev/null | \
- while read -r hash i; do
- case $i in
- *^{}) ;;
- refs/*) echo ${i#refs/*/} ;;
- *) echo $i ;;
- esac
- done
+ echo HEAD
+ git for-each-ref --format=%(refname:short) --
refs/remotes/$dir/ | sed -e s#^$dir/##
Yeah, this patch makes sense overall. I'm curious as to what role
ORG_HEAD had to play originally, and why it's absent now.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: avoid ls-remote in certain scenarios
On Tue, May 28, 2013 at 10:20:48PM -0500, Felipe Contreras wrote:
It's _very_ slow in many cases, and there's really no point in fetching
*everything* from the remote just for completion. In many cases it might
be faster for the user to type the whole thing.
If the user manually specifies 'refs/*', then the full ls-remote
completion is triggered.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 1c35eef..2ce4f7d 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -427,14 +427,8 @@ __git_refs ()
done
;;
*)
- git ls-remote $dir HEAD ORIG_HEAD 'refs/tags/*'
'refs/heads/*' 'refs/remotes/*' 2/dev/null | \
- while read -r hash i; do
- case $i in
- *^{}) ;;
- refs/*) echo ${i#refs/*/} ;;
- *) echo $i ;;
- esac
- done
+ echo HEAD
+ git for-each-ref --format=%(refname:short) --
refs/remotes/$dir/ | sed -e s#^$dir/##
This case statement is only executed when $dir is not a git directory,
so what ensures that the cwd is in a git repo or work tree when
executing this brach of the case statement? What about 'git
--git-dir=/path/to/repo' invocations or when $GIT_DIR is specified?
Gábor
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
