git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tay Ray Chuan <rctay89@gmail.com>
To: "Git Mailing List" <git@vger.kernel.org>
Cc: "Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>
Subject: [PATCH v2 (resend)] ls-remote: fall-back to default remotes when no remote specified
Date: Thu,  8 Apr 2010 15:07:07 +0800	[thread overview]
Message-ID: <1270710427-6680-1-git-send-email-rctay89@gmail.com> (raw)
In-Reply-To: <1270699083-5424-1-git-send-email-rctay89@gmail.com>

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; if no suitable remote was found, then
exit with the usage text, as we do previously.

That 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.

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>
---
 builtin/ls-remote.c  |    5 ++---
 t/t5512-ls-remote.sh |   49 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 70f5622..efde78b 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -73,9 +73,6 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 		break;
 	}
 
-	if (!dest)
-		usage(ls_remote_usage);
-
 	if (argv[i]) {
 		int j;
 		pattern = xcalloc(sizeof(const char *), argc - i + 1);
@@ -87,6 +84,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 		}
 	}
 	remote = remote_get(dest);
+	if (!remote)
+		usage(ls_remote_usage);
 	if (!remote->url_nr)
 		die("remote %s has no configured URL", dest);
 	transport = transport_get(remote, NULL);
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 1dd8eed..341c79b 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -49,4 +49,53 @@ test_expect_success 'ls-remote self' '
 
 '
 
+test_expect_success 'dies when no remote specified and no default remotes found' '
+
+	test_must_fail git ls-remote
+
+'
+
+test_expect_success 'use "origin" when no remote specified' '
+
+	git remote add origin "$(pwd)/.git" &&
+	git ls-remote >actual &&
+	test_cmp expected.all actual
+
+'
+
+test_expect_success 'use branch.<name>.remote if possible' '
+
+	# Remove "origin" so that we know that ls-remote is not using it.
+	#
+	# Ideally, we should test that branch.<name>.remote takes precedence
+	# over "origin", but that is another matter altogether.
+	#
+	git remote rm origin &&
+	git config branch.master.remote self &&
+	git ls-remote >actual &&
+	test_cmp expected.all actual
+
+'
+
+cat >exp <<EOF
+fatal: 'refs*master' does not appear to be a git repository
+fatal: The remote end hung up unexpectedly
+EOF
+test_expect_success 'confuses pattern as remote when no remote specified' '
+	#
+	# Do not expect "git ls-remote <pattern>" to work; ls-remote, correctly,
+	# confuses <pattern> for <remote>. Although ugly, this behaviour is akin
+	# to the confusion of refspecs for remotes by git-fetch and git-push,
+	# eg:
+	#
+	#   $ git fetch branch
+	#
+
+	# We could just as easily have used "master"; the "*" emphasizes its
+	# role as a pattern.
+	test_must_fail git ls-remote refs*master >actual 2>&1 &&
+	test_cmp exp actual
+
+'
+
 test_done
-- 
1.7.0.97.g1372c

  parent reply	other threads:[~2010-04-08  7:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-08  3:58 [PATCH] ls-remote: default to 'origin' when no remote specified Tay Ray Chuan
2010-04-08  4:45 ` Jeff King
2010-04-08  5:35   ` Junio C Hamano
2010-04-08  6:25     ` Jeff King
2010-04-08  6:07   ` Tay Ray Chuan
2010-04-08  6:34     ` Jeff King
2010-04-08  6:44       ` Junio C Hamano
2010-04-08  6:47         ` Jeff King
2010-04-08  5:05 ` Junio C Hamano
2010-04-08  5:58   ` Tay Ray Chuan
2010-04-08  7:05 ` [PATCH v2] ls-remote: fall-back to default remotes " Tay Ray Chuan
2010-04-08  7:07 ` Tay Ray Chuan [this message]
2010-04-08  7:16   ` [PATCH v2 (resend)] " Jeff King
2010-04-08 17:10     ` Tay Ray Chuan
2010-04-08 17:21   ` [PATCH v3] " Tay Ray Chuan
2010-04-08 19:19     ` Jeff King
2010-04-09  8:49     ` Peter Kjellerstedt
2010-04-09  9:15       ` Tay Ray Chuan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1270710427-6680-1-git-send-email-rctay89@gmail.com \
    --to=rctay89@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).