summaryrefslogtreecommitdiff
path: root/t/t5800-remote-helpers.sh
AgeCommit message (Collapse)AuthorFilesLines
2012-10-08tests: "cp -a" is a GNUismLibravatar Ben Walton1-1/+1
These tests just want a bit-for-bit identical copy; they do not need even -H (there is no symbolic link involved) nor -p (there is no funny permission or ownership issues involved). Just use "cp -R" instead. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24git-remote-testgit: fix race when spawning fast-importLibravatar Pete Wyckoff1-0/+13
Test "pushing to local repo" in t5800-remote-helpers can hang due to a race condition in git-remote-testgit. Fix it by setting stdin to unbuffered. On the writer side, "git push" invokes push_refs_with_export(), which sends to stdout the command "export\n" and immediately starts up "git fast-export". The latter writes its output stream to the same stdout. On the reader side, remote helper "git-remote-testgit" reads from stdin to get its next command. It uses getc() to read characters from libc up until \n. Libc has buffered a potentially much larger chunk of stdin. When it sees the "export\n" command, it forks "git fast-import" to read the stream. If fast-export finishes before git fast-import starts, the fast-export output can end up in libc's buffer in git-remote-testgit, rather than in git fast-import. The latter hangs indefinitely on a now-empty stdin. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: change import semanticsLibravatar Sverre Rabbelier1-1/+1
Currently the helper must somehow guess how many import statements to read before it starts outputting its fast-export stream. This is because the remote helper infrastructure runs fast-import only once, so the helper is forced to output one stream for all import commands it will receive. The only reason this worked in the past was because only one ref was imported at a time. Change the semantics of the import statement such that it matches that of the push statement. That is, the import statement is followed by a series of import statements that are terminated by a '\n'. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19git_remote_helpers: push all refs during a non-local exportLibravatar Jeff King1-1/+1
When a remote helper exports to a non-local git repo, the steps are roughly: 1. fast-export into a local staging area; the set of interesting refs is defined by what is in the fast-export stream 2. git push from the staging area to the non-local repo In the second step, we should explicitly push all refs, not just matching ones. This will let us push refs that do not yet exist in the remote repo. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: don't feed bogus refs to export pushLibravatar Jeff King1-1/+1
When we want to push to a remote helper that has the "export" capability, we collect all of the refs we want to push and then feed them to fast-export. However, the list of refs is actually a list of remote refs, not local refs. The mapped local refs are included via the peer_ref pointer. So when we add an argument to our fast-export command line, we must be sure to use the local peer_ref name (and if there is no local name, it is because we are not actually sending that ref, or we may not even have the ref at all). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19git-remote-testgit: import non-HEAD refsLibravatar Jeff King1-1/+1
Upon receiving an "import" command, the testgit remote helper would ignore the ref asked for by git and generate a fast-export stream based on HEAD. Instead, we should actually give git the ref it asked for. This requires adding a new parameter to the export_repo method in the remote-helpers python library, which may be used by code outside of git.git. We use a default parameter so that callers without the new parameter will get the same behavior as before. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19t5800: document some non-functional parts of remote helpersLibravatar Jeff King1-0/+47
These are all things one might expect to work in a helper that is capable of handling multiple branches (which our testgit helper in theory should be able to do, as it is backed by git). All of these bugs are specific to the import/export codepaths, so they don't affect helpers like git-remote-curl that use fetch/push commands. The first and fourth tests are about fetching and pushing new refs, and demonstrate bugs in the git_remote_helpers library (so they would be most likely to impact helpers for other VCSs which import/export git). The second test is about importing multiple refs; it demonstrates a bug in git-remote-testgit, which is mostly for exercising the test code. Therefore it probably doesn't affect anyone in practice. The third test demonstrates a bug in git's side of the helper code when the upstream has added refs that we do not have locally. This could impact git users who use remote helpers to access foreign VCSs. All of those bugs have fixes later in this series. The fifth test is the most complex, and does not have a fix in this series. It tests pushing a ref via the export mechanism to a new name on the remote side (i.e., "git push $remote old:new"). The problem is that we push all of the work of generating the export stream onto fast-export, but we have no way of communicating to fast-export that this name mapping is happening. So we tell fast-export to generate a stream with the commits for "old", but we can't tell it to label them all as "new". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19t5800: use skip_all instead of prereqLibravatar Sverre Rabbelier1-15/+19
All tests require python 2.4 or higher. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19t5800: factor out some ref testsLibravatar Jeff King1-4/+8
These are a little hard to read, and I'm about to add more just like them. Plus the failure output is nicer if we use test_cmp than a comparison with "test". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t/t5800-remote-helpers.sh: Skip with prereq on python <2.4Libravatar Ævar Arnfjörð Bjarmason1-13/+11
Change the t/t5800-remote-helpers.sh test to skip with the the three-arg prereq form of test_expect_success instead of bailing out. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-08tests: Use skip_all=* to skip testsLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change tests to skip with skip_all=* + test_done instead of using say + test_done. This is a follow-up to "tests: Skip tests in a way that makes sense under TAP" (fadb5156e4). I missed these cases when prepearing that patch, hopefully this is all of them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-13Remove python 2.5'ismsLibravatar Brandon Casey1-2/+2
The following python 2.5 features were worked around: * the sha module is used as a fallback when the hashlib module is not available * the 'any' built-in method was replaced with a 'for' loop * a conditional expression was replaced with an 'if' statement * the subprocess.check_call method was replaced by a call to subprocess.Popen followed by a call to subprocess.wait with a check of its return status These changes allow the python infrastructure to be used with python 2.4 which is distributed with RedHat's RHEL 5, for example. t5800 was updated to check for python >= 2.4 to reflect these changes. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02t/t5800: skip if python version is older than 2.5Libravatar Brandon Casey1-2/+8
This test script depends on the git-remote-testgit python script. This python script makes use of the hashlib module which was released in python version 2.5. So, add a new pre-requisite named PYTHON_2_5_OR_NEWER to test-lib.sh and check for it in t5800. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-12t5800: testgit helper requires Python supportLibravatar Jonathan Nieder1-0/+6
git remote-testgit is written in Python. In a NO_PYTHON build, tests using it would fail, so skip them. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-04remote-helpers: add tests for testgit helperLibravatar Sverre Rabbelier1-0/+70
[jc: with test fixes from J6t] Signed-off-by: Junio C Hamano <gitster@pobox.com>