path: root/t/
AgeCommit message (Collapse)Author
2020-06-18Merge branch 'js/reflog-anonymize-for-clone-and-fetch'Junio C Hamano
The reflog entries for "git clone" and "git fetch" did not anonymize the URL they operated on. * js/reflog-anonymize-for-clone-and-fetch: clone/fetch: anonymize URLs in the reflog
2020-06-04clone/fetch: anonymize URLs in the reflogJohannes Schindelin
Even if we strongly discourage putting credentials into the URLs passed via the command-line, there _is_ support for that, and users _do_ do that. Let's scrub them before writing them to the reflog. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-04-17transport-helper: mark failure for atomic pushJiang Xin
Commit v2.22.0-1-g3bca1e7f9f (transport-helper: enforce atomic in push_refs_with_push, 2019-07-11) noticed the incomplete report of failure of an atomic push for HTTP protocol. But the implementation has a flaw that mark all remote references as failure. Only mark necessary references as failure in `push_refs_with_push()` of transport-helper. Signed-off-by: Jiang Xin <> Signed-off-by: Junio C Hamano <>
2020-04-17send-pack: mark failure of atomic push properlyJiang Xin
When pushing with SSH or other smart protocol, references are validated by function `check_to_send_update()` before they are sent in commands to `send_pack()` of "receve-pack". For atomic push, if a reference is rejected after the validation, only references pushed by user should be marked as failure, instead of report failure on all remote references. Commit v2.22.0-1-g3bca1e7f9f (transport-helper: enforce atomic in push_refs_with_push, 2019-07-11) wanted to fix report issue of HTTP protocol, but marked all remote references failure for atomic push. In order to fix the issue of status report for SSH or other built-in smart protocol, revert part of that commit and add additional status for function `atomic_push_failure()`. The additional status for it except the "REF_STATUS_EXPECTING_REPORT" status are: - REF_STATUS_NONE : Not marked as "REF_STATUS_EXPECTING_REPORT" yet. - REF_STATUS_OK : Assume OK for dryrun or status_report is disabled. This fix won't resolve the issue of status report in transport-helper for HTTP or other protocols, and breaks test case in t5541. Will fix it in additional commit. Signed-off-by: Jiang Xin <> Signed-off-by: Junio C Hamano <>
2020-01-15test: request GIT_TEST_PROTOCOL_VERSION=0 when appropriateJonathan Nieder
Since 8cbeba0632 (tests: define GIT_TEST_PROTOCOL_VERSION, 2019-02-25), it has been possible to run tests with a newer protocol version by setting the GIT_TEST_PROTOCOL_VERSION envvar to a version number. Tests that assume protocol v0 handle this by explicitly setting GIT_TEST_PROTOCOL_VERSION= or similar constructs like 'test -z "$GIT_TEST_PROTOCOL_VERSION" || return 0' to declare that they only handle the default (v0) protocol. The emphasis there is a bit off: it would be clearer to specify GIT_TEST_PROTOCOL_VERSION=0 to inform the reader that these tests are specifically testing and relying on details of protocol v0. Do so. This way, a reader does not need to know what the default protocol version is, and the tests can continue to work when the default protocol version used by Git advances past v0. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2019-10-23Merge branch 'bc/smart-http-atomic-push'Junio C Hamano
The atomic push over smart HTTP transport did not work, which has been corrected. * bc/smart-http-atomic-push: remote-curl: pass on atomic capability to remote side
2019-10-17remote-curl: pass on atomic capability to remote sidebrian m. carlson
When pushing more than one reference with the --atomic option, the server is supposed to perform a single atomic transaction to update the references, leaving them either all to succeed or all to fail. This works fine when pushing locally or over SSH, but when pushing over HTTP, we fail to pass the atomic capability to the remote side. In fact, we have not reported this capability to any remote helpers during the life of the feature. Now normally, things happen to work nevertheless, since we actually check for most types of failures, such as non-fast-forward updates, on the client side, and just abort the entire attempt. However, if the server side reports a problem, such as the inability to lock a ref, the transaction isn't atomic, because we haven't passed the appropriate capability over and the remote side has no way of knowing that we wanted atomic behavior. Fix this by passing the option from the transport code through to remote helpers, and from the HTTP remote helper down to send-pack. With this change, we can detect if the server side rejects the push and report back appropriately. Note the difference in the messages: the remote side reports "atomic transaction failed", while our own checking rejects pushes with the message "atomic push failed". Document the atomic option in the remote helper documentation, so other implementers can implement it if they like. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2019-09-17Revert "progress: use term_clear_line()"SZEDER Gábor
This reverts commit 5b12e3123b (progress: use term_clear_line(), 2019-06-24), because covering up the entire last line while refreshing the progress line caused unexpected problems during 'git clone/fetch/push': $ git clone ssh://localhost/home/szeder/src/tmp/linux.git/ Cloning into 'linux'... remote: remote: remote: remote: Enumerating objects: 999295 The length of the progress bar line can shorten when it includes throughput and the unit changes, or when its length exceeds the width of the terminal and is broken into two lines. In these cases the previously displayed longer progress line should be covered up, because otherwise the leftover characters from the previous progress line make the output look weird [1]. term_clear_line() makes this quite simple, as it covers up the entire last line either by using an ANSI control sequence or by printing a terminal width worth of space characters, depending on whether the terminal is smart or dumb. Unfortunately, when accessing a remote repository via any non-local protocol the remote 'git receive-pack/upload-pack' processes can't possibly have any idea about the local terminal (smart of dumb? how wide?) their progress will end up on. Consequently, they assume the worst, i.e. standard-width dumb terminal, and print 80 spaces to cover up the previously displayed progress line. The local 'git clone/fetch/push' processes then display the remote's progress, including these coverup spaces, with the 'remote: ' prefix, resulting in a total line length of 88 characters. If the local terminal is narrower than that, then the coverup gets line-wrapped, and after that the CR at the end doesn't return to the beginning of the progress line, but to the first column of its last line, resulting in those repeated 'remote: <many-spaces>' lines. By reverting 5b12e3123b (progress: use term_clear_line(), 2019-06-24) we won't cover up the entire last line, but go back to comparing the length of the current progress bar line with the previous one, and cover up as many characters as needed. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2019-07-25Merge branch 'es/local-atomic-push-failure-with-http'Junio C Hamano
"git push --atomic" that goes over the transport-helper (namely, the smart http transport) failed to prevent refs to be pushed when it can locally tell that one of the ref update will fail without having to consult the other end, which has been corrected. * es/local-atomic-push-failure-with-http: transport-helper: avoid var decl in for () loop control transport-helper: enforce atomic in push_refs_with_push
2019-07-12transport-helper: enforce atomic in push_refs_with_pushEmily Shaffer
Teach transport-helper how to notice if skipping a ref during push would violate atomicity on the client side. We notice that a ref would be rejected, and choose not to send it, but don't notice that if the client has asked for --atomic we are violating atomicity if all the other pushes we are sending would succeed. Asking the server end to uphold atomicity wouldn't work here as the server doesn't have any idea that we tried to update a ref that's broken. The added test-case is a succinct way to reproduce this issue that fails today. The same steps work fine when we aren't using a transport-helper to get to the upstream, i.e. when we've added a local repository as a remote: git remote add ~/upstream upstream Signed-off-by: Emily Shaffer <> Signed-off-by: Junio C Hamano <>
2019-06-27progress: use term_clear_line()SZEDER Gábor
To make sure that the previously displayed progress line is completely covered up when the new line is shorter, commit 545dc345eb (progress: break too long progress bar lines, 2019-04-12) added a bunch of calculations to figure out how many characters it needs to overwrite with spaces. Use the just introduced term_clear_line() helper function to, well, clear the last line, making all these calculations unnecessary, and thus simplifying the code considerably. Three tests in '' 'grep' for specific text shown in the progress lines at the beginning of the line, but now those lines begin either with the ANSI escape sequence or with the terminal width worth of space characters clearing the line. Relax the 'grep' patterns to match anywhere on the line. Note that only two of these three tests fail without relaxing their 'grep' pattern, but the third looks for the absence of the pattern, so it still succeeds, but without the adjustment would potentially hide future regressions. Note also that with this change we no longer need the length of the previously displayed progress line, so the strbuf added to 'struct progress' in d53ba841d4 (progress: assemble percentage and counters in a strbuf before printing, 2019-04-05) is not strictly necessary anymore. We still keep it, though, as it avoids allocating and releasing a strbuf each time the progress is updated. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2019-04-25Merge branch 'sg/test-atexit'Junio C Hamano
Test framework update to more robustly clean up leftover files and processes after tests are done. * sg/test-atexit: t9811-git-p4-label-import: fix pipeline negation git p4 test: disable '-x' tracing in the p4d watchdog loop git p4 test: simplify timeout handling git p4 test: clean up the p4d cleanup functions git p4 test: use 'test_atexit' to kill p4d and the watchdog process t0301-credential-cache: use 'test_atexit' to stop the credentials helper tests: use 'test_atexit' to stop httpd git-daemon: use 'test_atexit` to stop 'git-daemon' test-lib: introduce 'test_atexit' t/lib-git-daemon: make sure to kill the 'git-daemon' process test-lib: fix interrupt handling with 'dash' and '--verbose-log -x'
2019-03-14tests: use 'test_atexit' to stop httpdSZEDER Gábor
Use 'test_atexit' to run cleanup commands to stop httpd at the end of the test script or upon interrupt or failure, as it is shorter, simpler, and more robust than registering such cleanup commands in the trap on EXIT in the test scripts. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2019-03-07tests: fix protocol version for overspecificationsJonathan Tan
These tests are also marked with a NEEDSWORK comment. Signed-off-by: Jonathan Tan <> Signed-off-by: Junio C Hamano <>
2018-08-27Merge branch 'sg/test-must-be-empty'Junio C Hamano
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>'SZEDER Gábor
Using 'test_must_be_empty' is more idiomatic than 'test_cmp /dev/null out', and its message on error is perhaps a bit more to the point. This patch was basically created by running: sed -i -e 's%test_cmp /dev/null%test_must_be_empty%' t[0-9]*.sh with the exception of the change in 'should not fail in an empty repo' in '', where it was 'test_cmp output /dev/null'. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-08-02Merge branch 'sg/httpd-test-unflake'Junio C Hamano
httpd tests saw occasional breakage due to the way its access log gets inspected by the tests, which has been updated to make them less flaky. * sg/httpd-test-unflake: t/lib-httpd: avoid occasional failures when checking access.log t/lib-httpd: add the strip_access_log() helper function t5541: clean up truncating access log
2018-07-12t/lib-httpd: avoid occasional failures when checking access.logSZEDER Gábor
The last test of '', 'server request log matches test results' may fail occasionally, because the order of entries in Apache's access log doesn't match the order of requests sent in the previous tests, although all the right requests are there. I saw it fail on Travis CI five times in the span of about half a year, when the order of two subsequent requests was flipped, and could trigger the failure with a modified Git. However, I was unable to trigger it with stock Git on my machine. Three tests in '' and '' check requests in the log the same way, so they might be prone to a similar occasional failure as well. When a test sends a HTTP request, it can continue execution after 'git-http-backend' fulfilled that request, but Apache writes the corresponding access log entry only after 'git-http-backend' exited. Some time inevitably passes between fulfilling the request and writing the log entry, and, under unfavourable circumstances, enough time might pass for the subsequent request to be sent and fulfilled by a different Apache thread or process, and then Apache writes access log entries racily. This effect can be exacerbated by adding a bit of variable delay after the request is fulfilled but before 'git-http-backend' exits, e.g. like this: diff --git a/http-backend.c b/http-backend.c index f3dc218b2..bbf4c125b 100644 --- a/http-backend.c +++ b/http-backend.c @@ -709,5 +709,7 @@ int cmd_main(int argc, const char **argv) max_request_buffer); cmd->imp(&hdr, cmd_arg); + if (getpid() % 2) + sleep(1); return 0; } This delay considerably increases the chances of log entries being written out of order, and in turn makes t5561's last test fail almost every time. Alas, it doesn't seem to be enough to trigger a similar failure in t5541 and t5551. So, since we can't just rely on the order of access log entries always corresponding the order of requests, make checking the access log more deterministic by sorting (simply lexicographically) both the stripped access log entries and the expected entries before the comparison with 'test_cmp'. This way the order of log entries won't matter and occasional out-of-order entries won't trigger a test failure, but the comparison will still notice any unexpected or missing log entries. OTOH, this sorting will make it harder to identify from which test an unexpected log entry came from or which test's request went missing. Therefore, in case of an error include the comparison of the unsorted log enries in the test output as well. And since all this should be performed in four tests in three test scripts, put this into a new helper function 'check_access_log' in 't/'. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-07-12t/lib-httpd: add the strip_access_log() helper functionSZEDER Gábor
Four tests in three httpd-related test scripts check the contents of Apache's 'access.log', and they all do so by running 'sed' with the exact same script consisting of four s/// commands to strip uninteresting log fields and to vertically align the requested URLs. Extract this into a common helper function 'strip_access_log' in '', and use it in all of those tests. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-07-12t5541: clean up truncating access logSZEDER Gábor
In the second test of '', 'no empty path components' we truncate Apache's access log by running: echo >.../access.log There are two issues with this approach: - This doesn't leave an empty file behind, like a proper truncation would, but a file with a lone newline in it. Consequently, a later test checking the log's contents must consider this improper truncation and include an empty line in the expected content. - This truncation is done in the middle of the test, because, quoting the in-code comment, "we do this [truncation] before the actual comparison to ensure the log is cleared" even when subsequent 'test_cmp' fails. Alas, this is not quite robust enough, as it is conceivable that 'git clone' fails after already having sent a request, in which case the access log would not be truncated and would leave stray log entries behind. Since there is no need for that newline at all, drop the 'echo' from the truncation and adjust the expected content accordingly. Furthermore, make sure that the truncation is performed no matter whether and how 'git clone' fails unexpectedly by specifying it as a 'test_when_finished' command. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-04-24push: test to verify that push errors are coloredJohannes Schindelin
This actually only tests whether the push errors/hints are colored if the respective color.* config settings are `always`, but in the regular case they default to `auto` (in which case we color the messages when stderr is connected to an interactive terminal), therefore these tests should suffice. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-02-08t5541: add 'test_i18ngrep's missing filename parameterSZEDER Gábor
The test 'push --no-progress silences progress but not status' runs 'test_i18ngrep' without specifying a filename parameter. This has remained unnoticed since its introduction in e304aeba2 (t5541: test more combinations of --progress, 2012-05-01), because that 'test_i18ngrep' is supposed to check that the given pattern is not present in its input, and of course it won't find that pattern if its input is empty (as it comes from /dev/null). This also means that this test could miss a potential breakage of 'git push --no-progress'. Signed-off-by: SZEDER Gábor <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <> use the GIT_TRACE_CURL environment varElia Pinto
Use the new GIT_TRACE_CURL environment variable instead of the deprecated GIT_CURL_VERBOSE. Signed-off-by: Elia Pinto <> Signed-off-by: Junio C Hamano <>
2016-07-25Merge branch 'jk/push-scrub-url'Junio C Hamano
"git fetch http://user:pass@host/repo..." scrubbed the userinfo part, but "git push" didn't. * jk/push-scrub-url: t5541: fix url scrubbing test when GPG is not set push: anonymize URL in status output
2016-07-20t5541: fix url scrubbing test when GPG is not setJeff King
When the GPG prereq is not set, we do not run test 34. That test changes the directory of the test script as a side effect (something we usually frown on, but which matches the style of the rest of this script). When test 35 (the url-scrubbing test) runs, it expects to be in the directory from test 34. If it's not, the test fails; we are in a different sub-repo, our test-commit is built on a different history, and the push becomes a non-fast-forward. We can fix this by unconditionally moving to the directory we expect (again, against our usual style but matching how the rest of the script operates). As an additional protection, let's also switch from "make a new commit and push to master" to just "push to a new branch". We don't care about the branch name; we just want _some_ ref update to trigger the status output. Pushing to a new branch is less likely to run into problems with force-updates, changing the checked-out branch, etc. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-07-14push: anonymize URL in status outputJeff King
Commit 47abd85 (fetch: Strip usernames from url's before storing them, 2009-04-17) taught fetch to anonymize URLs. The primary purpose there was to avoid sticking passwords in merge-commit messages, but as a side effect, we also avoid printing them to stderr. The push side does not have the merge-commit problem, but it probably should avoid printing them to stderr. We can reuse the same anonymizing function. Note that for this to come up, the credentials would have to appear either on the command line or in a git config file, neither of which is particularly secure. So people _should_ be switching to using credential helpers instead, which makes this problem go away. But that's no excuse not to improve the situation for people who for whatever reason end up using credentials embedded in the URL. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-07-01t5541: become resilient to GETTEXT_POISONVasco Almeida
Use test_i18n* functions for testing text already marked for translation. Signed-off-by: Vasco Almeida <> Signed-off-by: Junio C Hamano <>
2015-06-05Merge branch 'jk/skip-http-tests-under-no-curl' into maintJunio C Hamano
Test clean-up. * jk/skip-http-tests-under-no-curl: tests: skip dav http-push tests under NO_EXPAT=NoThanks t/ skip tests if NO_CURL is defined
2015-05-22Merge branch 'jk/skip-http-tests-under-no-curl'Junio C Hamano
Test clean-up. * jk/skip-http-tests-under-no-curl: tests: skip dav http-push tests under NO_EXPAT=NoThanks t/ skip tests if NO_CURL is defined
2015-05-07t/ skip tests if NO_CURL is definedJeff King
If we built git without curl, we can't actually test against an http server. In fact, all of the test scripts which include already perform this check, with one exception: t5540. For those scripts, this is a noop, and for t5540, this is a bugfix (it used to fail when built with NO_CURL, though it could go unnoticed if you had a stale git-remote-https in your build directory). Noticed-by: Junio C Hamano <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-03-26Merge branch 'jk/test-chain-lint'Junio C Hamano
People often forget to chain the commands in their test together with &&, leaving a failure from an earlier command in the test go unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to catch such a mistake more easily. * jk/test-chain-lint: (36 commits) t9001: drop save_confirm helper t0020: use test_* helpers instead of hand-rolled messages t: simplify loop exit-code status variables t: fix some trivial cases of ignored exit codes in loops t7701: fix ignored exit code inside loop t3305: fix ignored exit code inside loop t0020: fix ignored exit code inside loops perf-lib: fix ignored exit code inside loop t6039: fix broken && chain t9158, t9161: fix broken &&-chain in git-svn tests t9104: fix test for following larger parents t4104: drop hand-rolled error reporting t0005: fix broken &&-chains t7004: fix embedded single-quotes t0050: appease --chain-lint t9001: use test_when_finished t4117: use modern test_* helpers t6034: use modern test_* helpers t1301: use modern test_* helpers t0020: use modern test_* helpers ...
2015-03-20t: fix trivial &&-chain breakageJeff King
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-03-13t5541: move run_with_cmdline_limit to test-lib.shJeff King
We use this to test http pushing with a restricted commandline. Other scripts (like t5551, which does http fetching) will want to use it, too. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-10-08Merge branch 'jc/push-cert'Junio C Hamano
Allow "git push" request to be signed, so that it can be verified and audited, using the GPG signature of the person who pushed, that the tips of branches at a public repository really point the commits the pusher wanted to, without having to "trust" the server. * jc/push-cert: (24 commits) receive-pack::hmac_sha1(): copy the entire SHA-1 hash out signed push: allow stale nonce in stateless mode signed push: teach smart-HTTP to pass "git push --signed" around signed push: fortify against replay attacks signed push: add "pushee" header to push certificate signed push: remove duplicated protocol info send-pack: send feature request on push-cert packet receive-pack: GPG-validate push certificates push: the beginning of "git push --signed" pack-protocol doc: typofix for PKT-LINE gpg-interface: move parse_signature() to where it should be gpg-interface: move parse_gpg_output() to where it should be send-pack: clarify that cmds_sent is a boolean send-pack: refactor inspecting and resetting status and sending commands send-pack: rename "new_refs" to "need_pack_data" receive-pack: factor out capability string generation send-pack: factor out capability string generation send-pack: always send capabilities send-pack: refactor decision to send update per ref send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher ...
2014-09-17signed push: allow stale nonce in stateless modeJunio C Hamano
When operating with the stateless RPC mode, we will receive a nonce issued by another instance of us that advertised our capability and refs some time ago. Update the logic to check received nonce to detect this case, compute how much time has passed since the nonce was issued and report the status with a new environment variable GIT_PUSH_CERT_NONCE_SLOP to the hooks. GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The hooks are free to decide how large a slop it is willing to accept. Strictly speaking, the "nonce" is not really a "nonce" anymore in the stateless RPC mode, as it will happily take any "nonce" issued by it (which is protected by HMAC and its secret key) as long as it is fresh enough. The degree of this security degradation, relative to the native protocol, is about the same as the "we make sure that the 'git push' decided to update our refs with new objects based on the freshest observation of our refs by making sure the values they claim the original value of the refs they ask us to update exactly match the current state" security is loosened to accomodate the stateless RPC mode in the existing code without this series, so there is no need for those who are already using smart HTTP to push to their repositories to be alarmed any more than they already are. In addition, the server operator can set receive.certnonceslop configuration variable to specify how stale a nonce can be (in seconds). When this variable is set, and if the nonce received in the certificate that passes the HMAC check was less than that many seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS (instead of "SLOP") and the received nonce value is given in GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded hook to check if the certificate we received is recent enough. Signed-off-by: Junio C Hamano <>
2014-09-17signed push: teach smart-HTTP to pass "git push --signed" aroundJunio C Hamano
The "--signed" option received by "git push" is first passed to the transport layer, which the native transport directly uses to notice that a push certificate needs to be sent. When the transport-helper is involved, however, the option needs to be told to the helper with set_helper_option(), and the helper needs to take necessary action. For the smart-HTTP helper, the "necessary action" involves spawning the "git send-pack" subprocess with the "--signed" option. Once the above all gets wired in, the smart-HTTP transport now can use the push certificate mechanism to authenticate its pushes. Add a test that is modeled after tests for the native transport in to Update the test Apache configuration to pass GNUPGHOME environment variable through. As PassEnv would trigger warnings for an environment variable that is not set, export it from set to a harmless value when GnuPG is not being used in the tests. Note that the added test is deliberately loose and does not check the nonce in this step. This is because the stateless RPC mode is inevitably flaky and a nonce that comes back in the actual push processing is one issued by a different process; if the two interactions with the server crossed a second boundary, the nonces will not match and such a check will fail. A later patch in the series will work around this shortcoming. Signed-off-by: Junio C Hamano <>
2014-08-26send-pack: take refspecs over stdinJeff King
Pushing a large number of refs works over most transports, because we implement send-pack as an internal function. However, it can sometimes fail when pushing over http, because we have to spawn "git send-pack --stateless-rpc" to do the heavy lifting, and we pass each refspec on the command line. This can cause us to overflow the OS limits on the size of the command line for a large push. We can solve this by giving send-pack a --stdin option and using it from remote-curl. We already dealt with this on the fetch-pack side in 078b895 (fetch-pack: new --stdin option to read refs from stdin, 2012-04-02). The stdin option (and in particular, its use of packet-lines for stateless-rpc input) is modeled after that solution. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-02-10test: rename http fetch and push test filesNguyễn Thái Ngọc Duy
Make clear which one is for dumb protocol, which one is for smart from their file name. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>