# [PATCH] completion: avoid ls-remote in certain scenarios 6 messages from 2013-05-29 to 2013-06-02. Participants: Felipe Contreras, SZEDER Gábor, Ramkumar Ramachandra, Junio C Hamano. Thread: https://gitlist.dev/t/33964 ## Felipe Contreras, 2013-05-29 03:20 Subject: [PATCH] completion: avoid ls-remote in certain scenarios Message-ID: <1369797648-2921-1-git-send-email-felipe.contreras@gmail.com> URL: https://gitlist.dev/e/1369797648-2921-1-git-send-email-felipe.contreras%40gmail.com ``` 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 --- 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 } -- 1.8.3.rc3.312.g47657de ``` ## SZEDER Gábor, 2013-05-29 07:44 Subject: Re: [PATCH] completion: avoid ls-remote in certain scenarios Message-ID: <20130529074408.GA7955@goldbirke> URL: https://gitlist.dev/e/20130529074408.GA7955%40goldbirke In-Reply-To: <1369797648-2921-1-git-send-email-felipe.contreras@gmail.com> ``` 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 > --- > 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 ``` ## Felipe Contreras, 2013-06-01 13:58 Subject: Re: [PATCH] completion: avoid ls-remote in certain scenarios Message-ID: URL: https://gitlist.dev/e/CAMP44s3abuEuXdRsAkuCVZiBkaFc%2BpT3kfXK9uN-U7tc4CR3tA%40mail.gmail.com In-Reply-To: <20130529074408.GA7955@goldbirke> ``` On Wed, May 29, 2013 at 2:44 AM, SZEDER Gábor wrote: > 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 >> --- >> 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? 'git --git-dir=foo fetch ' doesn't even work. I sent the patches to fix it, but as usual, nobody cared about actual real fixes. $GIT_DIR works fine, why wouldn't it? -- Felipe Contreras ``` ## Ramkumar Ramachandra, 2013-06-01 18:25 Subject: Re: [PATCH] completion: avoid ls-remote in certain scenarios Message-ID: URL: https://gitlist.dev/e/CALkWK0nXPA7Rhcp1Reb0oBMXmW5SkL7zhy1786L9CjE74x7xTg%40mail.gmail.com In-Reply-To: <1369797648-2921-1-git-send-email-felipe.contreras@gmail.com> ``` 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. ``` ## Junio C Hamano, 2013-06-02 22:08 Subject: Re: [PATCH] completion: avoid ls-remote in certain scenarios Message-ID: <7vip1wmahf.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vip1wmahf.fsf%40alter.siamese.dyndns.org In-Reply-To: <1369797648-2921-1-git-send-email-felipe.contreras@gmail.com> ``` Felipe Contreras 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/ 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/ 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 > --- > 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 > } ``` ## Felipe Contreras, 2013-06-02 22:57 Subject: Re: [PATCH] completion: avoid ls-remote in certain scenarios Message-ID: URL: https://gitlist.dev/e/CAMP44s0or-wtNc85HPO8hMA47xbcXVOcF0QcWvpLAyay0bB2Ag%40mail.gmail.com In-Reply-To: <7vip1wmahf.fsf@alter.siamese.dyndns.org> ``` On Sun, Jun 2, 2013 at 5:08 PM, Junio C Hamano wrote: > Felipe Contreras 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/ > > 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 ' 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/ > > 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/ Would still complete everything. -- Felipe Contreras ```