]> git.ipfire.org Git - thirdparty/git.git/commit - t/t9902-completion.sh
completion: list short refs from a remote given as a URL
authorSZEDER Gábor <szeder.dev@gmail.com>
Fri, 3 Feb 2017 02:48:20 +0000 (03:48 +0100)
committerJunio C Hamano <gitster@pobox.com>
Sat, 4 Feb 2017 06:18:40 +0000 (22:18 -0800)
commit91b7ea81e87e9c0fd485edf39f0ad982d0350110
treed41ac9659f6091576ae8107308e0a6e26cefe218
parent62a1b732160c363a84be310f801b5dec59196b9c
completion: list short refs from a remote given as a URL

e832f5c09680 (completion: avoid ls-remote in certain scenarios,
2013-05-28) turned a 'git ls-remote <remote>' query into a 'git
for-each-ref refs/remotes/<remote>/' to improve responsiveness of
remote refs completion by avoiding potential network communication.
However, it inadvertently made impossible to complete short refs from
a remote given as a URL, e.g. 'git fetch git://server.com/repo.git
<TAB>', because there is, of course, no such thing as
'refs/remotes/git://server.com/repo.git'.

Since the previous commit we tell apart configured remotes, i.e. those
that can have a hierarchy under 'refs/remotes/', from others that
don't, including remotes given as URL, so we know when we can't use
the faster 'git for-each-ref'-based approach.

Resurrect the old, pre-e832f5c09680 'git ls-remote'-based code for the
latter case to support listing short refs from remotes given as a URL.
The code is slightly updated from the original to

  - take into account the path to the repository given on the command
    line (if any), and
  - omit 'ORIG_HEAD' from the query, as 'git ls-remote' will never
    list it anyway.

When the remote given to __git_refs() doesn't exist, then it will be
handled by this resurrected 'git ls-remote' query.  This code path
doesn't list 'HEAD' unconditionally, which has the nice side effect of
fixing two more expected test failures.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib/completion/git-completion.bash
t/t9902-completion.sh