summaryrefslogtreecommitdiff
path: root/t/t5800-remote-helpers.sh
AgeCommit message (Collapse)Author
2011-07-19transport-helper: change import semanticsSverre Rabbelier
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 exportJeff King
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 pushJeff King
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 refsJeff King
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 helpersJeff King
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 prereqSverre Rabbelier
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 testsJeff King
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.4Ævar Arnfjörð Bjarmason
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-09tests: Use skip_all=* to skip testsÆvar Arnfjörð Bjarmason
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-14Remove python 2.5'ismsBrandon Casey
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.5Brandon Casey
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-13t5800: testgit helper requires Python supportJonathan Nieder
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 helperSverre Rabbelier
[jc: with test fixes from J6t] Signed-off-by: Junio C Hamano <gitster@pobox.com>