summaryrefslogtreecommitdiff
path: root/t/t5512-ls-remote.sh
AgeCommit message (Collapse)AuthorFilesLines
2012-07-04Merge branch 'hv/remote-end-hung-up'Libravatar Junio C Hamano1-9/+7
When we get disconnected while expecting a response from the remote side because authentication failed, we issued an error message "The remote side hung up unexpectedly." Give hint that it may be a permission problem in the message when we can reasonably suspect it. * hv/remote-end-hung-up: remove the impression of unexpectedness when access is denied
2012-06-19remove the impression of unexpectedness when access is deniedLibravatar Heiko Voigt1-9/+7
If a server accessed through ssh is denying access git will currently issue the message "fatal: The remote end hung up unexpectedly" as the last line. This sounds as if something really ugly just happened. Since this is a quite typical situation in which users regularly get we do not say that if it happens at the beginning when reading the remote heads. If its in the very first beginning of reading the remote heads it is very likely an authentication error or a missing repository. If it happens later during reading the remote heads we still indicate that it happened during this initial contact phase. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-02t5512 (ls-remote): modernize styleLibravatar Tom Grennan1-23/+4
Prepare expected output inside test_expect_success that uses it. Also remove excess blank lines. Signed-off-by: Tom Grennan <tmgrennan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-18ls-remote: the --exit-code option reports "no matching refs"Libravatar Michael Schubert1-0/+24
The "git ls-remote" uses its exit status to indicate if it successfully talked with the remote repository. A new option "--exit-code" makes the command exit with status "2" when there is no refs to be listed, even when the command successfully talked with the remote repository. This way, the caller can tell if we failed to contact the remote, or the remote did not have what we wanted to see. Of course, you can inspect the output from the command, which has been and will continue to be a valid way to check the same thing. Signed-off-by: Michael Schubert <mschub@elegosoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-11ls-remote: print URL when no repo is specifiedLibravatar Tay Ray Chuan1-4/+20
After 9c00de5 (ls-remote: fall-back to default remotes when no remote specified), when no repository is specified, ls-remote may use the URL/remote in the config "branch.<name>.remote" or the remote "origin"; it may not be immediately obvious to the user which was used. In such cases, print a simple "From <URL>" line to indicate which repository was used. This message is similar to git-fetch's, and is printed to stderr to avoid breaking existing scripts that depend on ls-remote's output behaviour. It can also be disabled with -q/--quiet. Modify tests related to falling back on default remotes to check for this as well, and add a test to check for suppression of the message. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-08ls-remote: fall-back to default remotes when no remote specifiedLibravatar Tay Ray Chuan1-0/+58
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>
2008-05-05Fix tests breaking when checkout path contains shell metacharactersLibravatar Bryan Donlan1-1/+1
This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-13add test_cmp function for test scriptsLibravatar Jeff King1-4/+4
Many scripts compare actual and expected output using "diff -u". This is nicer than "cmp" because the output shows how the two differ. However, not all versions of diff understand -u, leading to unnecessary test failure. This adds a test_cmp function to the test scripts and switches all "diff -u" invocations to use it. The function uses the contents of "$GIT_TEST_CMP" to compare its arguments; the default is "diff -u". On systems with a less-capable diff, you can do: GIT_TEST_CMP=cmp make test Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-06Reteach builtin-ls-remote to understand remotesLibravatar Shawn O. Pearce1-0/+52
Prior to being made a builtin git-ls-remote understood that when it was given a remote name we wanted it to resolve that to the pre-configured URL and connect to that location. That changed when it was converted to a builtin and many of my automation tools broke. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>