delta/git.git/t/t5512-ls-remote.sh, branch ss/userdiff-update-csharp-java

upload/receive-pack: allow hiding ref hierarchies

2013-02-07T21:48:47+00:00

A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.

Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable.  Do the same to receive-pack via the
receive.hiderefs variable.  As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.

Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).

Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.

An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected.  This
is not a new restriction.  To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs.  I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit".  The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.

Signed-off-by: Junio C Hamano

Merge branch 'hv/remote-end-hung-up'

2012-07-05T06:40:12+00:00

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

remove the impression of unexpectedness when access is denied

2012-06-19T20:37:02+00:00

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 
Signed-off-by: Junio C Hamano

t5512 (ls-remote): modernize style

2012-03-03T06:26:34+00:00

Prepare expected output inside test_expect_success that uses it.
Also remove excess blank lines.

Signed-off-by: Tom Grennan 
Signed-off-by: Junio C Hamano

ls-remote: the --exit-code option reports "no matching refs"

2011-05-18T21:37:46+00:00

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 
Signed-off-by: Junio C Hamano

ls-remote: print URL when no repo is specified

2010-05-12T05:55:44+00:00

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..remote" or the remote
"origin"; it may not be immediately obvious to the user which was used.

In such cases, print a simple "From " 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 
Signed-off-by: Junio C Hamano

ls-remote: fall-back to default remotes when no remote specified

2010-04-09T06:10:43+00:00

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..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 " 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 
Acked-by: Jeff King 
Signed-off-by: Junio C Hamano

Fix tests breaking when checkout path contains shell metacharacters

2008-05-05T21:37:02+00:00

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 
Signed-off-by: Junio C Hamano

add test_cmp function for test scripts

2008-03-13T07:57:52+00:00

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 
Signed-off-by: Junio C Hamano

Reteach builtin-ls-remote to understand remotes

2007-11-07T06:51:04+00:00

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 
Signed-off-by: Junio C Hamano