ls-remote: fall-back to default remotes when no remote specified
authorTay Ray Chuan <rctay89@gmail.com>
Thu, 8 Apr 2010 17:21:13 +0000 (01:21 +0800)
committerJunio C Hamano <gitster@pobox.com>
Fri, 9 Apr 2010 06:10:43 +0000 (23:10 -0700)
commit9c00de5a3135c8f7273668d4013c225d48d47861
treed1c2d579b2bd922e51a71159263437aca4740e2f
parent02125bcc41aed022ddcb5955935726e50d89b60e
ls-remote: fall-back to default remotes when no remote specified

Instead of breaking execution when no remote (as specified in the
variable dest) is specified when git-ls-remote is invoked, continue on
and let remote_get() handle it.

This way, we are able to use the default remotes (eg. "origin",
branch.<name>.remote), as git-fetch, git-push, and other users of
remote_get(), do.

If no suitable remote is found, exit with a message describing the
issue, instead of just the usage text, as we do previously.

Add several tests to check that git-ls-remote handles the
no-remote-specified situation.

Also add a test that "git ls-remote <pattern>" does not work; we are
unable to guess the remote in that situation, as are git-fetch and
git-push.

In that test, we are testing for messages coming from two separate
processes, but we should be OK, because the second message is triggered
by closing the fd which must happen after the first message is printed.
(analysis by Jeff King.)

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/ls-remote.c
t/t5512-ls-remote.sh