summaryrefslogtreecommitdiff
path: root/t/t5512-ls-remote.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-11-16ref-filter: don't look for objects when outside of a repositoryLibravatar SZEDER Gábor1-0/+6
The command 'git ls-remote --sort=authordate <remote>' segfaults when run outside of a repository, ever since the introduction of its '--sort' option in 1fb20dfd8e (ls-remote: create '--sort' option, 2018-04-09). While in general the 'git ls-remote' command can be run outside of a repository just fine, its '--sort=<key>' option with certain keys does require access to the referenced objects. This sorting is implemented using the generic ref-filter sorting facility, which already handles missing objects gracefully with the appropriate 'missing object deadbeef for HEAD' message. However, being generic means that it checks replace refs while trying to retrieve an object, and while doing so it accesses the 'git_replace_ref_base' variable, which has not been initialized and is still a NULL pointer when outside of a repository, thus causing the segfault. Make ref-filter more careful upfront while parsing the format string, and make it error out when encountering a format atom requiring object access when we are not in a repository. Also add a test to ensure that 'git ls-remote --sort' fails gracefully when executed outside of a repository. Reported-by: H.Merijn Brand <h.m.brand@xs4all.nl> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'jk/proto-v2-ref-prefix-fix'Libravatar Junio C Hamano1-0/+18
"git ls-remote $there foo" was broken by recent update for the protocol v2 and stopped showing refs that match 'foo' that are not refs/{heads,tags}/foo, which has been fixed. * jk/proto-v2-ref-prefix-fix: ls-remote: pass heads/tags prefixes to transport ls-remote: do not send ref prefixes for patterns
2018-10-31ls-remote: pass heads/tags prefixes to transportLibravatar Jeff King1-0/+9
Unlike its arbitrary text patterns, the --heads and --tags options to ls-remote are true prefixes. We can pass this information to the transport code. If the v2 protocol is in use, that will reduce the size of the ref advertisement. Note that the test added here succeeds both before and after the patch. This is an optimization, not a bug-fix; it's just making sure we didn't break anything. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31ls-remote: do not send ref prefixes for patternsLibravatar Jeff King1-0/+9
Since b4be74105f (ls-remote: pass ref prefixes when requesting a remote's refs, 2018-03-15), "ls-remote foo" will pass "refs/heads/foo", "refs/tags/foo", etc to the transport code in an attempt to let the other side reduce the size of its advertisement. Unfortunately this is not correct, as ls-remote patterns do not follow the usual ref lookup rules, and are in fact tail-matched. So we could find "refs/heads/foo" or "refs/heads/a/much/deeper/foo" or even "refs/another/hierarchy/foo". Since we can't pass a prefix and there's not yet a v2 extension for matching wildcards, we must disable this feature to keep the same behavior as v1. Reported-by: Jon Simons <jon@jonsimons.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20Merge branch 'ab/test-must-be-empty-for-master'Libravatar Junio C Hamano1-4/+2
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-07-30tests: make use of the test_must_be_empty functionLibravatar Ævar Arnfjörð Bjarmason1-4/+2
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t5000-t5999: fix broken &&-chainsLibravatar Eric Sunshine1-2/+2
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t5512: run git fetch inside testLibravatar René Scharfe1-1/+1
Do the preparatory fetch inside the test of ls-remote --symref to avoid cluttering the test output and to be able to catch unexpected fetch failures. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09ls-remote: create '--sort' optionLibravatar Harald Nordgren1-7/+47
Create a '--sort' option for ls-remote, based on the one from for-each-ref. This e.g. allows ref names to be sorted by version semantics, so that v1.2 is sorted before v1.10. Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-26wrapper.c: add and use fopen_or_warn()Libravatar Nguyễn Thái Ngọc Duy1-3/+10
When fopen() returns NULL, it could be because the given path does not exist, but it could also be some other errors and the caller has to check. Add a wrapper so we don't have to repeat the same error check everywhere. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14remote: avoid reading $GIT_DIR config in non-repoLibravatar Jeff King1-0/+9
The "git ls-remote" command can be run outside of a repository, but needs to look up configured remotes. The config code is smart enough to handle this case itself, but we also check the historical "branches" and "remotes" paths in $GIT_DIR. The git_path() function causes us to blindly look at ".git/remotes", even if we know we aren't in a git repository. For now, this is just an unlikely bug (you probably don't have such a file if you're not in a repository), but it will become more obvious once we merge b1ef400ee (setup_git_env: avoid blind fall-back to ".git", 2016-10-20): [now] $ git ls-remote fatal: No remote configured to list refs from. [with b1ef400ee] $ git ls-remote fatal: BUG: setup_git_env called without repository We can fix this by skipping these sources entirely when we're outside of a repository. The test is a little more complex than the demonstration above. Rather than detect the correct behavior by parsing the error message, we can actually set up a case where the remote name we give is a valid repository, but b1ef400ee would cause us to die in the configuration step. This test doesn't fail now, but it future-proofs us for the b1ef400ee change. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26Merge branch 'va/i18n-more'Libravatar Junio C Hamano1-1/+1
Even more i18n. * va/i18n-more: i18n: stash: mark messages for translation i18n: notes-merge: mark die messages for translation i18n: ident: mark hint for translation i18n: i18n: diff: mark die messages for translation i18n: connect: mark die messages for translation i18n: commit: mark message for translation
2016-09-19i18n: connect: mark die messages for translationLibravatar Vasco Almeida1-1/+1
Mark messages passed to die() in die_initial_contact(). Update test to reflect changes. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-09connect: advertized capability is not a refLibravatar Jonathan Tan1-0/+40
When cloning an empty repository served by standard git, "git clone" produces the following reassuring message: $ git clone git://localhost/tmp/empty Cloning into 'empty'... warning: You appear to have cloned an empty repository. Checking connectivity... done. Meanwhile when cloning an empty repository served by JGit, the output is more haphazard: $ git clone git://localhost/tmp/empty Cloning into 'empty'... Checking connectivity... done. warning: remote HEAD refers to nonexistent ref, unable to checkout. This is a common command to run immediately after creating a remote repository as preparation for adding content to populate it and pushing. The warning is confusing and needlessly worrying. The cause is that, since v3.1.0.201309270735-rc1~22 (Advertise capabilities with no refs in upload service., 2013-08-08), JGit's ref advertisement includes a ref named capabilities^{} to advertise its capabilities on, while git's ref advertisement is empty in this case. This allows the client to learn about the server's capabilities and is needed, for example, for fetch-by-sha1 to work when no refs are advertised. This also affects "ls-remote". For example, against an empty repository served by JGit: $ git ls-remote git://localhost/tmp/empty 0000000000000000000000000000000000000000 capabilities^{} Git advertises the same capabilities^{} ref in its ref advertisement for push but since it never did so for fetch, the client didn't need to handle this case. Handle it. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19ls-remote: add support for showing symrefsLibravatar Thomas Gummerer1-0/+45
Sometimes it's useful to know the main branch of a git repository without actually downloading the repository. This can be done by looking at the symrefs stored in the remote repository. Currently git doesn't provide a simple way to show the symrefs stored on the remote repository, even though the information is available. Add a --symref command line argument to the ls-remote command, which shows the symrefs in the remote repository. While there, replace a literal tab in the format string with \t to make it more obvious to the reader. Suggested-by: pedro rijo <pedrorijo91@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-07refs: support negative transfer.hideRefsLibravatar Jeff King1-0/+23
If you hide a hierarchy of refs using the transfer.hideRefs config, there is no way to later override that config to "unhide" it. This patch implements a "negative" hide which causes matches to immediately be marked as unhidden, even if another match would hide it. We take care to apply the matches in reverse-order from how they are fed to us by the config machinery, as that lets our usual "last one wins" config precedence work (and entries in .git/config, for example, will override /etc/gitconfig). So you can now do: $ git config --system transfer.hideRefs refs/secret $ git config transfer.hideRefs '!refs/secret/not-so-secret' to hide refs/secret in all repos, except for one public bit in one specific repo. Or you can even do: $ git clone \ -u "git -c transfer.hiderefs="!refs/foo" upload-pack" \ remote:repo.git to clone remote:repo.git, overriding any hiding it has configured. There are two alternatives that were considered and rejected: 1. A generic config mechanism for removing an item from a list. E.g.: (e.g., "[transfer] hideRefs -= refs/foo"). This is nice because it could apply to other multi-valued config, as well. But it is not nearly as flexible. There is no way to say: [transfer] hideRefs = refs/secret hideRefs = refs/secret/not-so-secret Having explicit negative specifications means we can override previous entries, even if they are not the same literal string. 2. Adding another variable to override some parts of hideRefs (e.g., "exposeRefs"). This solves the problem from alternative (1), but it cannot easily obey the normal config precedence, because it would use two separate lists. For example: [transfer] hideRefs = refs/secret exposeRefs = refs/secret/not-so-secret hideRefs = refs/secret/not-so-secret/no-really-its-secret With two lists, we have to apply the "expose" rules first, and only then apply the "hide" rules. But that does not match what the above config intends. Of course we could internally parse that to a single list, respecting the ordering, which saves us having to invent the new "!" syntax. But using a single name communicates to the user that the ordering _is_ important. And "!" is well-known for negation, and should not appear at the beginning of a ref (it is actually valid in a ref-name, but all entries here should be fully-qualified, starting with "refs/"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: wrap complicated expect_code users in a blockLibravatar Jeff King1-2/+4
If we are expecting a command to produce a particular exit code, we can use test_expect_code. However, some cases are more complicated, and want to accept one of a range of exit codes. For these, we end up with something like: cmd; case "$?" in ... That unfortunately breaks the &&-chain and fools --chain-lint. Since these special cases are so few, we can wrap them in a block, like this: { cmd; ret=$?; } && case "$ret" in ... This accomplishes the same thing, and retains the &&-chain (the exit status fed to the && is that of the assignment, which should always be true). It's technically longer, but it is probably a good thing for unusual code like this to stand out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07upload/receive-pack: allow hiding ref hierarchiesLibravatar Junio C Hamano1-0/+12
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 <gitster@pobox.com>
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>