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.
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).
So I think overall the above makes sense.
> 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/##"
> ;;
> esac
> }
--
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
