summaryrefslogtreecommitdiff
path: root/transport-helper.c
AgeCommit message (Collapse)AuthorFilesLines
2014-01-17Merge branch 'nd/shallow-clone'Libravatar Junio C Hamano1-0/+6
Fetching from a shallow-cloned repository used to be forbidden, primarily because the codepaths involved were not carefully vetted and we did not bother supporting such usage. This attempts to allow object transfer out of a shallow-cloned repository in a controlled way (i.e. the receiver become a shallow repository with truncated history). * nd/shallow-clone: (31 commits) t5537: fix incorrect expectation in test case 10 shallow: remove unused code send-pack.c: mark a file-local function static git-clone.txt: remove shallow clone limitations prune: clean .git/shallow after pruning objects clone: use git protocol for cloning shallow repo locally send-pack: support pushing from a shallow clone via http receive-pack: support pushing to a shallow clone via http smart-http: support shallow fetch/clone remote-curl: pass ref SHA-1 to fetch-pack as well send-pack: support pushing to a shallow clone receive-pack: allow pushes that update .git/shallow connected.c: add new variant that runs with --shallow-file add GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses receive/send-pack: support pushing from a shallow clone receive-pack: reorder some code in unpack() fetch: add --update-shallow to accept refs that update .git/shallow upload-pack: make sure deepening preserves shallow roots fetch: support fetching from a shallow repository clone: support remote shallow repository ...
2013-12-10smart-http: support shallow fetch/cloneLibravatar Nguyễn Thái Ngọc Duy1-0/+6
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05replace {pre,suf}fixcmp() with {starts,ends}_with()Libravatar Christian Couder1-8/+8
Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-31transport-helper: trivial style fixLibravatar Felipe Contreras1-0/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-12Merge branch 'mm/mediawiki-dumb-push-fix'Libravatar Junio C Hamano1-2/+5
* mm/mediawiki-dumb-push-fix: git-remote-mediawiki: no need to update private ref in non-dumb push git-remote-mediawiki: use no-private-update capability on dumb push transport-helper: add no-private-update capability git-remote-mediawiki: add test and check Makefile targets
2013-09-09Merge branch 'jc/push-cas'Libravatar Junio C Hamano1-2/+28
Allow a safer "rewind of the remote tip" push than blind "--force", by requiring that the overwritten remote ref to be unchanged since the new history to replace it was prepared. The machinery is more or less ready. The "--force" option is again the big red button to override any safety, thanks to J6t's sanity (the original round allowed --lockref to defeat --force). The logic to choose the default implemented here is fragile (e.g. "git fetch" after seeing a failure will update the remote-tracking branch and will make the next "push" pass, defeating the safety pretty easily). It is suitable only for the simplest workflows, and it may hurt users more than it helps them. * jc/push-cas: push: teach --force-with-lease to smart-http transport send-pack: fix parsing of --force-with-lease option t5540/5541: smart-http does not support "--force-with-lease" t5533: test "push --force-with-lease" push --force-with-lease: tie it all together push --force-with-lease: implement logic to populate old_sha1_expect[] remote.c: add command line option parser for "--force-with-lease" builtin/push.c: use OPT_BOOL, not OPT_BOOLEAN cache.h: move remote/connect API out of it
2013-09-09Merge branch 'nd/clone-connectivity-shortcut'Libravatar Junio C Hamano1-0/+10
* nd/clone-connectivity-shortcut: smart http: use the same connectivity check on cloning
2013-09-03transport-helper: add no-private-update capabilityLibravatar Matthieu Moy1-2/+5
Since 664059fb (transport-helper: update remote helper namespace, 2013-04-17), a 'push' operation on a remote helper updates the private ref by default. This is often a good thing, but it can also be desirable to disable this update to force the next 'pull' to re-import the pushed revisions. Allow remote-helpers to disable the automatic update by introducing a new capability. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02push: teach --force-with-lease to smart-http transportLibravatar Junio C Hamano1-2/+22
We have been passing enough information to enable the compare-and-swap logic down to the transport layer, but the transport helper was not passing it to smart-http transport. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-29many small typofixesLibravatar Ondřej Bílka1-2/+2
Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Reviewed-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23smart http: use the same connectivity check on cloningLibravatar Nguyễn Thái Ngọc Duy1-0/+10
This is an extension of c6807a4 (clone: open a shortcut for connectivity check - 2013-05-26) to reduce the cost of connectivity check at clone time, this time with smart http protocol. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22push --force-with-lease: tie it all togetherLibravatar Junio C Hamano1-0/+6
This teaches the deepest part of the callchain for "git push" (and "git send-pack") to enforce "the old value of the ref must be this, otherwise fail this push" (aka "compare-and-swap" / "--lockref"). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Merge branch 'jk/gcc-function-attributes'Libravatar Junio C Hamano1-1/+2
Use the function attributes extension to catch mistakes in use of our own variadic functions that use NULL sentinel at the end (i.e. like execl(3)) and format strings (i.e. like printf(3)). * jk/gcc-function-attributes: Add the LAST_ARG_MUST_BE_NULL macro wt-status: use "format" function attribute for status_printf use "sentinel" function attribute for variadic lists add missing "format" function attributes
2013-07-09add missing "format" function attributesLibravatar Jeff King1-1/+2
For most of our functions that take printf-like formats, we use gcc's __attribute__((format)) to get compiler warnings when the functions are misused. Let's give a few more functions the same protection. In most cases, the annotations do not uncover any actual bugs; the only code change needed is that we passed a size_t to transfer_debug, which expected an int. Since we expect the passed-in value to be a relatively small buffer size (and cast a similar value to int directly below), we can just cast away the problem. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-21transport-helper: be quiet on read errors from helpersLibravatar Jeff King1-1/+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-06-06Merge branch 'fc/transport-helper-no-refspec'Libravatar Junio C Hamano1-1/+12
With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run Detect such problematic cases and disable them for now. * fc/transport-helper-no-refspec: transport-helper: check if the dry-run is supported transport-helper: barf when user tries old:new
2013-05-29Merge branch 'fc/transport-helper-error-reporting'Libravatar Junio C Hamano1-16/+32
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-21transport-helper: check if the dry-run is supportedLibravatar Felipe Contreras1-0/+5
Certain remote-helpers (the ones with 'export') would try to push regardless. Obviously this is not what the user wants. Also, add a check for the 'dry-run' option, so remote-helpers can implement it. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-21transport-helper: barf when user tries old:newLibravatar Felipe Contreras1-2/+4
Otherwise with certain remote helpers (the ones that support 'export'), the users will be pushing to the wrong branch: git push topic:master Will push the topic branch, as if the user typed: git push topic Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-10transport-helper: fix remote helper namespace regressionLibravatar Felipe Contreras1-1/+1
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-09Sync with v1.8.2.3Libravatar Junio C Hamano1-2/+1
* maint: Git 1.8.2.3 t5004: avoid using tar for checking emptiness of archive t5004: ignore pax global header file mergetools/kdiff3: do not use --auto when diffing transport-helper: trivial style cleanup
2013-05-09transport-helper: trivial style cleanupLibravatar Felipe Contreras1-2/+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/+1
* fc/push-with-export-reporting-result: transport-helper: improve push messages
2013-05-05transport-helper: improve push messagesLibravatar Felipe Contreras1-0/+1
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-17transport-helper: update remote helper namespaceLibravatar Felipe Contreras1-4/+19
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: trivial code shuffleLibravatar Felipe Contreras1-5/+3
Just shuffle the die() part to make it more explicit, and cleanup the code-style. 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-0/+2
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-2/+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-1/+1
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/+5
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-1/+2
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-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-1/+1
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11transport-helper: improve push messagesLibravatar Felipe Contreras1-0/+1
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-4/+4
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-1/+1
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>
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCELibravatar Junio C Hamano1-0/+10
When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: require force for refs under refs/tags/Libravatar Chris Rorvick1-0/+6
References are allowed to update from one commit-ish to another if the former is an ancestor of the latter. This behavior is oriented to branches which are expected to move with commits. Tag references are expected to be static in a repository, though, thus an update to something under refs/tags/ should be rejected unless the update is forced. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-07When debug==1, start fast-import with "--stats" instead of "--quiet"Libravatar Florian Achleitner1-1/+1
fast-import prints statistics that could be interesting to the developer of remote helpers. Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Acked-by: David Michael Barr <b@rr-dav.id.au> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-07Connect fast-import to the remote-helper via pipe, adding 'bidi-import' ↵Libravatar Florian Achleitner1-13/+31
capability The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers to retrieve information about blobs and trees that already exist in fast-import's memory. This requires a channel from fast-import to the remote-helper. remote-helpers that use these features shall advertise the new 'bidi-import' capability to signal that they require the communication channel. When forking fast-import in transport-helper.c connect it to a dup of the remote-helper's stdin-pipe. The additional file descriptor is passed to fast-import via its command line (--cat-blob-fd). It follows that git and fast-import are connected to the remote-helpers's stdin. Because git can send multiple commands to the remote-helper on it's stdin, it is required that helpers that advertise 'bidi-import' buffer all input commands until the batch of 'import' commands is ended by a newline before sending data to fast-import. This is to prevent mixing commands and fast-import responses on the helper's stdin. Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Acked-by: David Michael Barr <b@rr-dav.id.au> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30Add explanatory comment for transport-helpers refs mapping.Libravatar Florian Achleitner1-0/+15
The patch below adds a comment to fetch_with_import() explaining the loop that saves the fetched commit names after 'git fast-import' has done its work. It avoids some confusion about which refs the fast-import stream is supposed to use to write its result. Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-30remove superfluous newlines in error messagesLibravatar Pete Wyckoff1-2/+2
The error handling routines add a newline. Remove the duplicate ones in error messages. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-26Merge branch 'sp/smart-http-failure-to-push'Libravatar Junio C Hamano1-3/+10
* sp/smart-http-failure-to-push: : Mask SIGPIPE on the command channel going to a transport helper disconnect from remote helpers more gently Conflicts: transport-helper.c
2012-02-23disconnect from remote helpers more gentlyLibravatar Jeff King1-3/+10
When git spawns a remote helper program (like git-remote-http), the last thing we do before closing the pipe to the child process is to send a blank line, telling the helper that we are done issuing commands. However, the helper may already have exited, in which case the parent git process will receive SIGPIPE and die. In particular, this can happen with the remote-curl helper when it encounters errors during a push. The helper reports individual errors for each ref back to git-push, and then exits with a non-zero exit code. Depending on the exact timing of the write, the parent process may or may not receive SIGPIPE. This causes intermittent test failure in t5541.8, and is a side effect of 5238cbf (remote-curl: Fix push status report when all branches fail). Before that commit, remote-curl would not send the final blank line to indicate that the list of status lines was complete; it would just exit, closing the pipe. The parent git-push would notice the closed pipe while reading the status report and exit immediately itself, propagating the failing exit code. But post-5238cbf, remote-curl completes the status list before exiting, git-push actually runs to completion, and then it tries to cleanly disconnect the helper, leading to the SIGPIPE race above. This patch drops all error-checking when sending the final "we are about to hang up" blank line to helpers. There is nothing useful for the parent process to do about errors at that point anyway, and certainly failing to send our "we are done with commands" line to a helper that has already exited is not a problem. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05remote: avoid passing NULL to read_ref()Libravatar Michael Haggerty1-2/+4
read_ref() can (and in test t5800, actually *does*) return NULL. Don't pass the NULL along to read_ref(). Coincidentally, this mistake didn't make resolve_ref() blow up, but upcoming changes to resolve_ref() will make it less forgiving. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05remote: use xstrdup() instead of strdup()Libravatar Michael Haggerty1-2/+2
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19transport-helper: die early on encountering deleted refsLibravatar Sverre Rabbelier1-0/+4
Remote helpers do not support deleting refs by means of the 'export' command sincethe fast-import protocol does not support it. Check explicitly for deleted refs and die early. 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-19transport-helper: implement marks location as capabilityLibravatar Sverre Rabbelier1-29/+18
Now that the gitdir location is exported as an environment variable this can be implemented elegantly without requiring any explicit flushes nor an ad-hoc exchange of values. 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-19transport-helper: Use capname for refspec capability tooLibravatar Sverre Rabbelier1-1/+1
Previously the refspec capability could not be listed as required or their parsing would break. Most likely the reason the second hunk wasn't caught is because the series that added 'refspec' as capability, and the one that added required capabilities were done in parallel. 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-19transport-helper: change import semanticsLibravatar Sverre Rabbelier1-0/+3
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-19transport-helper: update ref status after push with exportLibravatar Sverre Rabbelier1-0/+1
Also add check_output from python 2.7. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>