summaryrefslogtreecommitdiff
path: root/t/t5801-remote-helpers.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-06-21transport-helper: be quiet on read errors from helpersLibravatar Jeff King1-3/+1
Prior to commit 81d340d4, we did not print any error message if a remote transport helper died unexpectedly. If a helper did not print any error message (e.g., because it crashed), the user could be left confused. That commit tried to rectify the situation by printing a note that the helper exited unexpectedly. However, this makes a much more common case worse: when a helper does die with a useful message, we print the extra "Reading from 'git-remote-foo failed" message. This can also end up confusing users, as they may not even know what remote helpers are (e.g., the fact that http support comes through git-remote-https is purely an implementation detail that most users do not know or care about). Since we do not have a good way of knowing whether the helper printed a useful error, and since the common failure mode is for it to do so, let's default to remaining quiet. Debuggers can dig further by setting GIT_TRANSPORT_HELPER_DEBUG. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29Merge branch 'js/transport-helper-error-reporting-fix'Libravatar Junio C Hamano1-5/+0
Finishing touches to fc/transport-helper-error-reporting topic. * js/transport-helper-error-reporting-fix: git-remote-testgit: build it to run under $SHELL_PATH git-remote-testgit: further remove some bashisms git-remote-testgit: avoid process substitution
2013-05-29Merge branch 'fc/transport-helper-error-reporting'Libravatar Junio C Hamano1-20/+55
Update transport helper to report errors and maintain ref hierarchy used to keep track of remote helper state better. * fc/transport-helper-error-reporting: transport-helper: fix remote helper namespace regression test: remote-helper: add missing and t5801: "VAR=VAL shell_func args" is forbidden transport-helper: update remote helper namespace transport-helper: trivial code shuffle transport-helper: warn when refspec is not used transport-helper: clarify pushing without refspecs transport-helper: update refspec documentation transport-helper: clarify *:* refspec transport-helper: improve push messages transport-helper: mention helper name when it dies transport-helper: report errors properly
2013-05-10transport-helper: fix remote helper namespace regressionLibravatar Felipe Contreras1-0/+14
Commit 664059f (transport-helper: update remote helper namespace) updates the namespace when the push succeeds or not; we should do it only when it succeeded. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-10test: remote-helper: add missing andLibravatar Felipe Contreras1-1/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-05Merge branch 'fc/push-with-export-reporting-result'Libravatar Junio C Hamano1-0/+14
* fc/push-with-export-reporting-result: transport-helper: improve push messages
2013-05-05transport-helper: improve push messagesLibravatar Felipe Contreras1-0/+14
If there's already a remote-helper tracking ref, we can fetch the SHA-1 to report proper push messages (as opposed to always reporting [new branch]). The remote-helper currently can specify the old SHA-1 to avoid this problem, but there's no point in forcing all remote-helpers to be aware of git commit ids; they should be able to be agnostic of them. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-28git-remote-testgit: build it to run under $SHELL_PATHLibravatar Junio C Hamano1-5/+0
Just like all the other shell scripts, replace the shebang line to make sure it runs under the shell the user specified. As this no longer depends on bashisms, t5801 does not have to say bash must be available somewhere on the system. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-25t5801: "VAR=VAL shell_func args" is forbiddenLibravatar Junio C Hamano1-1/+3
It is not a portable expectation that a single-shot environment variable assignment works when calling a shell function, not a command. Set and export the variable before calling "test_must_fail git push" instead. This change would not hurt because this is the last command in the subprocess and the environment will not seep through to later tests without using a single-shot assignment. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: update remote helper namespaceLibravatar Felipe Contreras1-0/+12
When pushing, the remote namespace is updated correctly (e.g. refs/origin/master), but not the remote helper's (e.g. refs/testgit/origin/master), which currently is only updated while fetching. Since the remote namespace is used to tell fast-export which commits to avoid (because they were already imported/exported), it makes sense to have them in sync so they don't get generated twice. If the remote helper was implemented properly, they would be ignored, if not, they probably would end up repeated. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: warn when refspec is not usedLibravatar Felipe Contreras1-2/+4
For the modes that need it. In the future we should probably error out, instead of providing half-assed support. The reason we want to do this is because if it's not present, the remote helper might be updating refs/heads/*, or refs/remotes/origin/*, directly, and in the process fetch will get confused trying to update refs that are already updated, or older than what they should be. We shouldn't be messing with the rest of git. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: clarify pushing without refspecsLibravatar Felipe Contreras1-3/+3
This has never worked, since it's inception the code simply skips all the refs, essentially telling fast-export to do nothing. Let's at least tell the user what's going on. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: clarify *:* refspecLibravatar Felipe Contreras1-15/+0
The *:* refspec doesn't work, and never has, clarify the code and documentation to reflect that. This in effect reverts commit 9e7673e (gitremote-helpers(1): clarify refspec behaviour). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15transport-helper: add 'signed-tags' capabilityLibravatar John Keeping1-1/+11
This allows a remote helper using the 'export' protocol to specify that it supports signed tags, changing the handing from 'warn-strip' to 'verbatim'. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15transport-helper: pass --signed-tags=warn-strip to fast-exportLibravatar John Keeping1-0/+10
Currently, attempting to push a signed tag to a remote helper which uses fast-export results in the remote helper failing because the default fast-export action for signed tags is "abort". This is not helpful for users because there is no way to pass additional arguments to fast-export here, either from the remote helper or from the command line. In general, the signature will be invalidated by whatever transformation a remote helper performs on a tag to push it to a repository in a different format so the correct behaviour is to strip the tag. Doing this silently may surprise people, so use "warn-strip" to issue a warning when a signed tag is encountered. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11transport-helper: improve push messagesLibravatar Felipe Contreras1-0/+14
If there's already a remote-helper tracking ref, we can fetch the SHA-1 to report proper push messages (as opposed to always reporting [new branch]). The remote-helper currently can specify the old SHA-1 to avoid this problem, but there's no point in forcing all remote-helpers to be aware of git commit ids; they should be able to be agnostic of them. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11transport-helper: mention helper name when it diesLibravatar Jeff King1-1/+1
When we try to read from a remote-helper and get EOF or an error, we print a message indicating that the helper died. However, users may not know that a remote helper was in use (e.g., when using git-over-http), or even what a remote helper is. Let's print the name of the helper (e.g., "git-remote-https"); this makes it more obvious what the program is for, and provides a useful token for reporting bugs or searching for more information (e.g., in manpages). Signed-off-by: Jeff King <peff@peff.net> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11transport-helper: report errors properlyLibravatar Felipe Contreras1-0/+20
If a push fails because the remote-helper died (with fast-export), the user may not see any error message. We do correctly die with a failed exit code, as we notice that the helper has died while reading back the ref status from the helper. However, we don't print any message. This is OK if the helper itself printed a useful error message, but we cannot count on that; let's let the user know that the helper failed. In the long run, it may make more sense to propagate the error back up to push, so that it can present the usual status table and give a nicer message. But this is a much simpler fix that can help immediately. While we're adding tests, let's also confirm that the remote-helper dying is also detected when importing refs. We currently do so robustly when the helper uses the "done" feature (and that is what we test). We cannot do so reliably when the helper does not use the "done" feature, but it is not even worth testing; the right solution is for the helper to start using "done". Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03fast-export: make sure updated refs get updatedLibravatar Felipe Contreras1-12/+8
When an object has already been exported (and thus is in the marks) it's flagged as SHOWN, so it will not be exported again, even if in a later time it's exported through a different ref. We don't need the object to be exported again, but we want the ref updated, which doesn't happen. Since we can't know if a ref was exported or not, let's just assume that if the commit was marked (flags & SHOWN), the user still wants the ref updated. IOW: If it's specified in the command line, it will get updated, regardless of whether or not the object was marked. So: % git branch test master % git fast-export $mark_flags master % git fast-export $mark_flags test Would export 'test' properly. Additionally, this fixes issues with remote helpers; now they can push refs whose objects have already been exported, and a few other issues as well. Update the tests accordingly. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03fast-export: don't handle uninteresting refsLibravatar Felipe Contreras1-0/+8
They have been marked as UNINTERESTING for a reason, lets respect that. Currently the first ref is handled properly, but not the rest. Assuming that all the refs point at the same commit in the following example: % git fast-export master ^uninteresting ^foo ^bar reset refs/heads/bar from :0 reset refs/heads/foo from :0 reset refs/heads/uninteresting from :0 % git fast-export ^uninteresting ^foo ^bar master reset refs/heads/master from :0 reset refs/heads/bar from :0 reset refs/heads/foo from :0 Clearly this is wrong; the negative refs should be ignored. After this patch: % git fast-export ^uninteresting ^foo ^bar master # nothing % git fast-export master ^uninteresting ^foo ^bar # nothing And even more, it would only happen if the ref is pointing to exactly the same commit, but not otherwise: % git fast-export ^next next reset refs/heads/next from :0 % git fast-export ^next next^{commit} # nothing % git fast-export ^next next~0 # nothing % git fast-export ^next next~1 # nothing % git fast-export ^next next~2 # nothing The reason this happens is that before traversing the commits, fast-export checks if any of the refs point to the same object, and any duplicated ref gets added to a list in order to issue 'reset' commands after the traversing. Unfortunately, it's not even checking if the commit is flagged as UNINTERESTING. The fix of course, is to check it. However, in order to do it properly we need to get the UNINTERESTING flag from the command line, not from the commit object, because "^foo bar" will mark the commit 'bar' uninteresting if foo and bar points at the same commit. rev_cmdline_info, which was introduced exactly to handle this situation, contains all the information we need for get_tags_and_duplicates(), plus the ref flag. This way the rest of the positive refs will remain untouched; it's only the negative ones that change in behavior. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29remote-testgit: exercise more featuresLibravatar Felipe Contreras1-0/+52
Unfortunately a lot of these tests fail. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29remote-testgit: cleanup testsLibravatar Felipe Contreras1-34/+29
We don't need a bare 'server' and an intermediary 'public'. The repos can talk to each other directly; that's what we want to exercise. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29remote-testgit: remove irrelevant testLibravatar Felipe Contreras1-13/+0
This was only to cover a bug that was fixed in remote-testpy not to resurface. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29remote-testgit: remove non-local functionalityLibravatar Felipe Contreras1-29/+21
This only makes sense for the python remote helpers framework. The tests don't exercise any feature of transport helper. Remove them. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29Add new simplified git-remote-testgitLibravatar Felipe Contreras1-0/+139
Exercising the python remote helper framework is for another tool and another test. This is about testing the remote-helper interface. It's way simpler, it exercises the same features of remote helpers, it's easy to read and understand, and it doesn't depend on python. For now let's just copy the old remote-helpers test script, although some of those tests don't make sense. In addition, this script would be able to test other features not currently being tested. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>