Re: [PATCH] completion: avoid ls-remote in certain scenarios
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Jun 2, 2013, 22:57 UTC
- Message-ID
- <CAMP44s0or-wtNc85HPO8hMA47xbcXVOcF0QcWvpLAyay0bB2Ag@mail.gmail.com>
- In-Reply-To
- <7vip1wmahf.fsf@alter.siamese.dyndns.org>
On Sun, Jun 2, 2013 at 5:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> Felipe Contreras <felipe.contreras@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.
Show 9 quoted lines
> 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