2009-10-31 01:47:47 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2008 Clemens Buchacher <drizzd@aon.at>
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
test_description='test smart pushing over http via http-backend'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
ROOT_PATH="$PWD"
|
2014-09-15 23:59:00 +02:00
|
|
|
. "$TEST_DIRECTORY"/lib-gpg.sh
|
2009-10-31 01:47:47 +01:00
|
|
|
. "$TEST_DIRECTORY"/lib-httpd.sh
|
2012-01-08 22:06:21 +01:00
|
|
|
. "$TEST_DIRECTORY"/lib-terminal.sh
|
2009-10-31 01:47:47 +01:00
|
|
|
start_httpd
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup remote repository' '
|
|
|
|
|
cd "$ROOT_PATH" &&
|
|
|
|
|
mkdir test_repo &&
|
|
|
|
|
cd test_repo &&
|
|
|
|
|
git init &&
|
|
|
|
|
: >path1 &&
|
|
|
|
|
git add path1 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m initial &&
|
|
|
|
|
cd - &&
|
|
|
|
|
git clone --bare test_repo test_repo.git &&
|
|
|
|
|
cd test_repo.git &&
|
|
|
|
|
git config http.receivepack true &&
|
2012-03-30 09:01:30 +02:00
|
|
|
git config core.logallrefupdates true &&
|
2009-10-31 01:47:47 +01:00
|
|
|
ORIG_HEAD=$(git rev-parse --verify HEAD) &&
|
|
|
|
|
cd - &&
|
|
|
|
|
mv test_repo.git "$HTTPD_DOCUMENT_ROOT_PATH"
|
|
|
|
|
'
|
|
|
|
|
|
2012-08-27 15:25:36 +02:00
|
|
|
setup_askpass_helper
|
|
|
|
|
|
2010-04-08 04:15:16 +02:00
|
|
|
cat >exp <<EOF
|
|
|
|
|
GET /smart/test_repo.git/info/refs?service=git-upload-pack HTTP/1.1 200
|
|
|
|
|
POST /smart/test_repo.git/git-upload-pack HTTP/1.1 200
|
|
|
|
|
EOF
|
2010-04-08 04:15:18 +02:00
|
|
|
test_expect_success 'no empty path components' '
|
t5541: clean up truncating access log
In the second test of 't5541-http-push-smart.sh', '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 <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-12 14:22:14 +02:00
|
|
|
# Clear the log, so that it does not affect the "used receive-pack
|
|
|
|
|
# service" test which reads the log too.
|
|
|
|
|
test_when_finished ">\"\$HTTPD_ROOT_PATH\"/access.log" &&
|
|
|
|
|
|
2010-04-08 04:15:16 +02:00
|
|
|
# In the URL, add a trailing slash, and see if git appends yet another
|
|
|
|
|
# slash.
|
2009-10-31 01:47:47 +01:00
|
|
|
cd "$ROOT_PATH" &&
|
2010-04-08 04:15:16 +02:00
|
|
|
git clone $HTTPD_URL/smart/test_repo.git/ test_repo_clone &&
|
|
|
|
|
|
t/lib-httpd: avoid occasional failures when checking access.log
The last test of 't5561-http-backend.sh', '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
't5541-http-push-smart.sh' and 't5551-http-fetch-smart.sh' 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/lib-httpd.sh'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-12 14:22:16 +02:00
|
|
|
check_access_log exp
|
2010-04-08 04:15:16 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'clone remote repository' '
|
|
|
|
|
rm -rf test_repo_clone &&
|
2012-06-24 13:01:37 +02:00
|
|
|
git clone $HTTPD_URL/smart/test_repo.git test_repo_clone &&
|
|
|
|
|
(
|
|
|
|
|
cd test_repo_clone && git config push.default matching
|
|
|
|
|
)
|
2009-10-31 01:47:47 +01:00
|
|
|
'
|
|
|
|
|
|
2011-05-04 19:19:50 +02:00
|
|
|
test_expect_success 'push to remote repository (standard)' '
|
2009-10-31 01:47:47 +01:00
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
: >path2 &&
|
|
|
|
|
git add path2 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m path2 &&
|
|
|
|
|
HEAD=$(git rev-parse --verify HEAD) &&
|
2016-09-05 12:24:41 +02:00
|
|
|
GIT_TRACE_CURL=true git push -v -v 2>err &&
|
2011-05-04 19:19:50 +02:00
|
|
|
! grep "Expect: 100-continue" err &&
|
|
|
|
|
grep "POST git-receive-pack ([0-9]* bytes)" err &&
|
2009-10-31 01:47:47 +01:00
|
|
|
(cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
|
|
|
|
|
test $HEAD = $(git rev-parse --verify HEAD))
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'push already up-to-date' '
|
|
|
|
|
git push
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'create and delete remote branch' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
git checkout -b dev &&
|
|
|
|
|
: >path3 &&
|
|
|
|
|
git add path3 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m dev &&
|
|
|
|
|
git push origin dev &&
|
|
|
|
|
git push origin :dev &&
|
|
|
|
|
test_must_fail git show-ref --verify refs/remotes/origin/dev
|
|
|
|
|
'
|
|
|
|
|
|
remote-curl: Fix push status report when all branches fail
The protocol between transport-helper.c and remote-curl requires
remote-curl to always print a blank line after the push command
has run. If the blank line is ommitted, transport-helper kills its
container process (the git push the user started) with exit(128)
and no message indicating a problem, assuming the helper already
printed reasonable error text to the console.
However if the remote rejects all branches with "ng" commands in the
report-status reply, send-pack terminates with non-zero status, and
in turn remote-curl exited with non-zero status before outputting
the blank line after the helper status printed by send-pack. No
error messages reach the user.
This caused users to see the following from git push over HTTP
when the remote side's update hook rejected the branch:
$ git push http://... master
Counting objects: 4, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
$
Always print a blank line after the send-pack process terminates,
ensuring the helper status report (if it was output) will be
correctly parsed by the calling transport-helper.c. This ensures
the helper doesn't abort before the status report can be shown to
the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20 04:12:09 +01:00
|
|
|
cat >"$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update" <<EOF
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
exit 1
|
|
|
|
|
EOF
|
|
|
|
|
chmod a+x "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
|
|
|
|
|
|
|
|
|
|
cat >exp <<EOF
|
|
|
|
|
remote: error: hook declined to update refs/heads/dev2
|
|
|
|
|
To http://127.0.0.1:$LIB_HTTPD_PORT/smart/test_repo.git
|
|
|
|
|
! [remote rejected] dev2 -> dev2 (hook declined)
|
2012-02-13 21:17:14 +01:00
|
|
|
error: failed to push some refs to 'http://127.0.0.1:$LIB_HTTPD_PORT/smart/test_repo.git'
|
remote-curl: Fix push status report when all branches fail
The protocol between transport-helper.c and remote-curl requires
remote-curl to always print a blank line after the push command
has run. If the blank line is ommitted, transport-helper kills its
container process (the git push the user started) with exit(128)
and no message indicating a problem, assuming the helper already
printed reasonable error text to the console.
However if the remote rejects all branches with "ng" commands in the
report-status reply, send-pack terminates with non-zero status, and
in turn remote-curl exited with non-zero status before outputting
the blank line after the helper status printed by send-pack. No
error messages reach the user.
This caused users to see the following from git push over HTTP
when the remote side's update hook rejected the branch:
$ git push http://... master
Counting objects: 4, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
$
Always print a blank line after the send-pack process terminates,
ensuring the helper status report (if it was output) will be
correctly parsed by the calling transport-helper.c. This ensures
the helper doesn't abort before the status report can be shown to
the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20 04:12:09 +01:00
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'rejected update prints status' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
git checkout -b dev2 &&
|
|
|
|
|
: >path4 &&
|
|
|
|
|
git add path4 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m dev2 &&
|
|
|
|
|
test_must_fail git push origin dev2 2>act &&
|
|
|
|
|
sed -e "/^remote: /s/ *$//" <act >cmp &&
|
2016-06-30 18:49:18 +02:00
|
|
|
test_i18ncmp exp cmp
|
remote-curl: Fix push status report when all branches fail
The protocol between transport-helper.c and remote-curl requires
remote-curl to always print a blank line after the push command
has run. If the blank line is ommitted, transport-helper kills its
container process (the git push the user started) with exit(128)
and no message indicating a problem, assuming the helper already
printed reasonable error text to the console.
However if the remote rejects all branches with "ng" commands in the
report-status reply, send-pack terminates with non-zero status, and
in turn remote-curl exited with non-zero status before outputting
the blank line after the helper status printed by send-pack. No
error messages reach the user.
This caused users to see the following from git push over HTTP
when the remote side's update hook rejected the branch:
$ git push http://... master
Counting objects: 4, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
$
Always print a blank line after the send-pack process terminates,
ensuring the helper status report (if it was output) will be
correctly parsed by the calling transport-helper.c. This ensures
the helper doesn't abort before the status report can be shown to
the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20 04:12:09 +01:00
|
|
|
'
|
|
|
|
|
rm -f "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
|
|
|
|
|
|
2009-10-31 01:47:47 +01:00
|
|
|
cat >exp <<EOF
|
|
|
|
|
GET /smart/test_repo.git/info/refs?service=git-upload-pack HTTP/1.1 200
|
|
|
|
|
POST /smart/test_repo.git/git-upload-pack HTTP/1.1 200
|
|
|
|
|
GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
|
|
|
|
|
POST /smart/test_repo.git/git-receive-pack HTTP/1.1 200
|
|
|
|
|
GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
|
|
|
|
|
GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
|
|
|
|
|
POST /smart/test_repo.git/git-receive-pack HTTP/1.1 200
|
|
|
|
|
GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
|
|
|
|
|
POST /smart/test_repo.git/git-receive-pack HTTP/1.1 200
|
remote-curl: Fix push status report when all branches fail
The protocol between transport-helper.c and remote-curl requires
remote-curl to always print a blank line after the push command
has run. If the blank line is ommitted, transport-helper kills its
container process (the git push the user started) with exit(128)
and no message indicating a problem, assuming the helper already
printed reasonable error text to the console.
However if the remote rejects all branches with "ng" commands in the
report-status reply, send-pack terminates with non-zero status, and
in turn remote-curl exited with non-zero status before outputting
the blank line after the helper status printed by send-pack. No
error messages reach the user.
This caused users to see the following from git push over HTTP
when the remote side's update hook rejected the branch:
$ git push http://... master
Counting objects: 4, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
$
Always print a blank line after the send-pack process terminates,
ensuring the helper status report (if it was output) will be
correctly parsed by the calling transport-helper.c. This ensures
the helper doesn't abort before the status report can be shown to
the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20 04:12:09 +01:00
|
|
|
GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
|
|
|
|
|
POST /smart/test_repo.git/git-receive-pack HTTP/1.1 200
|
2009-10-31 01:47:47 +01:00
|
|
|
EOF
|
|
|
|
|
test_expect_success 'used receive-pack service' '
|
t/lib-httpd: avoid occasional failures when checking access.log
The last test of 't5561-http-backend.sh', '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
't5541-http-push-smart.sh' and 't5551-http-fetch-smart.sh' 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/lib-httpd.sh'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-12 14:22:16 +02:00
|
|
|
check_access_log exp
|
2009-10-31 01:47:47 +01:00
|
|
|
'
|
|
|
|
|
|
2010-03-02 11:49:26 +01:00
|
|
|
test_http_push_nonff "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git \
|
2013-08-03 00:14:50 +02:00
|
|
|
"$ROOT_PATH"/test_repo_clone master success
|
2010-01-08 03:12:40 +01:00
|
|
|
|
2010-01-08 03:12:44 +01:00
|
|
|
test_expect_success 'push fails for non-fast-forward refs unmatched by remote helper' '
|
2010-01-08 03:12:41 +01:00
|
|
|
# create a dissimilarly-named remote ref so that git is unable to match the
|
|
|
|
|
# two refs (viz. local, remote) unless an explicit refspec is provided.
|
2015-03-20 11:07:15 +01:00
|
|
|
git push origin master:retsam &&
|
2010-01-08 03:12:41 +01:00
|
|
|
|
|
|
|
|
echo "change changed" > path2 &&
|
|
|
|
|
git commit -a -m path2 --amend &&
|
|
|
|
|
|
|
|
|
|
# push master too; this ensures there is at least one '"'push'"' command to
|
|
|
|
|
# the remote helper and triggers interaction with the helper.
|
2011-02-23 00:42:12 +01:00
|
|
|
test_must_fail git push -v origin +master master:retsam >output 2>&1'
|
2010-01-08 03:12:41 +01:00
|
|
|
|
2011-02-23 00:42:12 +01:00
|
|
|
test_expect_success 'push fails for non-fast-forward refs unmatched by remote helper: remote output' '
|
2010-01-08 03:12:41 +01:00
|
|
|
grep "^ + [a-f0-9]*\.\.\.[a-f0-9]* *master -> master (forced update)$" output &&
|
2011-02-23 00:42:12 +01:00
|
|
|
grep "^ ! \[rejected\] *master -> retsam (non-fast-forward)$" output
|
|
|
|
|
'
|
2010-01-08 03:12:41 +01:00
|
|
|
|
2011-04-13 01:33:39 +02:00
|
|
|
test_expect_success 'push fails for non-fast-forward refs unmatched by remote helper: our output' '
|
2012-04-12 19:56:28 +02:00
|
|
|
test_i18ngrep "Updates were rejected because" \
|
2010-01-25 08:42:23 +01:00
|
|
|
output
|
2010-01-08 03:12:41 +01:00
|
|
|
'
|
|
|
|
|
|
2011-05-04 19:19:50 +02:00
|
|
|
test_expect_success 'push (chunked)' '
|
|
|
|
|
git checkout master &&
|
|
|
|
|
test_commit commit path3 &&
|
|
|
|
|
HEAD=$(git rev-parse --verify HEAD) &&
|
2013-03-24 22:06:08 +01:00
|
|
|
test_config http.postbuffer 4 &&
|
2011-05-04 19:19:50 +02:00
|
|
|
git push -v -v origin $BRANCH 2>err &&
|
|
|
|
|
grep "POST git-receive-pack (chunked)" err &&
|
|
|
|
|
(cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
|
|
|
|
|
test $HEAD = $(git rev-parse --verify HEAD))
|
|
|
|
|
'
|
|
|
|
|
|
remote-curl: don't pass back fake refs
When receive-pack advertises its list of refs, it generally hides the
capabilities information after a NUL at the end of the first ref.
However, when we have an empty repository, there are no refs, and
therefore receive-pack writes a fake ref "capabilities^{}" with the
capabilities afterwards.
On the client side, git reads the result with get_remote_heads(). We pick
the capabilities from the end of the line, and then call check_ref() to
make sure the ref name is valid. We see that it isn't, and don't bother
adding it to our list of refs.
However, the call to check_ref() is enabled by passing the REF_NORMAL flag
to get_remote_heads. For the regular git transport, we pass REF_NORMAL in
get_refs_via_connect() if we are doing a push (since only receive-pack
uses this fake ref). But in remote-curl, we never use this flag, and we
accept the fake ref as a real one, passing it back from the helper to the
parent git-push.
Most of the time this bug goes unnoticed, as the fake ref won't match our
refspecs. However, if "--mirror" is used, then we see it as remote cruft
to be pruned, and try to pass along a deletion refspec for it. Of course
this refspec has bogus syntax (because of the ^{}), and the helper
complains, aborting the push.
Let's have remote-curl mirror what the builtin get_refs_via_connect() does
(at least for the case of using git protocol; we can leave the dumb
info/refs reader as it is).
This also fixes pushing with --mirror to a smart-http remote that uses
alternates. The fake ".have" refs the server gives to avoid unnecessary
network transfer has a similar bad interactions with the machinery.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-17 11:45:39 +01:00
|
|
|
test_expect_success 'push --all can push to empty repo' '
|
|
|
|
|
d=$HTTPD_DOCUMENT_ROOT_PATH/empty-all.git &&
|
|
|
|
|
git init --bare "$d" &&
|
|
|
|
|
git --git-dir="$d" config http.receivepack true &&
|
|
|
|
|
git push --all "$HTTPD_URL"/smart/empty-all.git
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'push --mirror can push to empty repo' '
|
|
|
|
|
d=$HTTPD_DOCUMENT_ROOT_PATH/empty-mirror.git &&
|
|
|
|
|
git init --bare "$d" &&
|
|
|
|
|
git --git-dir="$d" config http.receivepack true &&
|
|
|
|
|
git push --mirror "$HTTPD_URL"/smart/empty-mirror.git
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'push --all to repo with alternates' '
|
|
|
|
|
s=$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git &&
|
|
|
|
|
d=$HTTPD_DOCUMENT_ROOT_PATH/alternates-all.git &&
|
|
|
|
|
git clone --bare --shared "$s" "$d" &&
|
|
|
|
|
git --git-dir="$d" config http.receivepack true &&
|
|
|
|
|
git --git-dir="$d" repack -adl &&
|
|
|
|
|
git push --all "$HTTPD_URL"/smart/alternates-all.git
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'push --mirror to repo with alternates' '
|
|
|
|
|
s=$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git &&
|
|
|
|
|
d=$HTTPD_DOCUMENT_ROOT_PATH/alternates-mirror.git &&
|
|
|
|
|
git clone --bare --shared "$s" "$d" &&
|
|
|
|
|
git --git-dir="$d" config http.receivepack true &&
|
|
|
|
|
git --git-dir="$d" repack -adl &&
|
|
|
|
|
git push --mirror "$HTTPD_URL"/smart/alternates-mirror.git
|
|
|
|
|
'
|
|
|
|
|
|
2012-05-01 10:43:08 +02:00
|
|
|
test_expect_success TTY 'push shows progress when stderr is a tty' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
test_commit noisy &&
|
|
|
|
|
test_terminal git push >output 2>&1 &&
|
2016-06-30 18:49:18 +02:00
|
|
|
test_i18ngrep "^Writing objects" output
|
2012-05-01 10:43:08 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success TTY 'push --quiet silences status and progress' '
|
2012-01-08 22:06:20 +01:00
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
test_commit quiet &&
|
2012-05-01 10:43:08 +02:00
|
|
|
test_terminal git push --quiet >output 2>&1 &&
|
2018-08-19 23:57:24 +02:00
|
|
|
test_must_be_empty output
|
2012-01-08 22:06:20 +01:00
|
|
|
'
|
|
|
|
|
|
2012-05-01 10:43:08 +02:00
|
|
|
test_expect_success TTY 'push --no-progress silences progress but not status' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
test_commit no-progress &&
|
|
|
|
|
test_terminal git push --no-progress >output 2>&1 &&
|
2016-06-30 18:49:18 +02:00
|
|
|
test_i18ngrep "^To http" output &&
|
2018-02-08 16:56:48 +01:00
|
|
|
test_i18ngrep ! "^Writing objects" output
|
2012-05-01 10:43:08 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'push --progress shows progress to non-tty' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
test_commit progress &&
|
|
|
|
|
git push --progress >output 2>&1 &&
|
2016-06-30 18:49:18 +02:00
|
|
|
test_i18ngrep "^To http" output &&
|
|
|
|
|
test_i18ngrep "^Writing objects" output
|
2012-05-01 10:43:08 +02:00
|
|
|
'
|
|
|
|
|
|
2012-03-30 09:01:30 +02:00
|
|
|
test_expect_success 'http push gives sane defaults to reflog' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
test_commit reflog-test &&
|
|
|
|
|
git push "$HTTPD_URL"/smart/test_repo.git &&
|
|
|
|
|
git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git" \
|
|
|
|
|
log -g -1 --format="%gn <%ge>" >actual &&
|
|
|
|
|
echo "anonymous <anonymous@http.127.0.0.1>" >expect &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'http push respects GIT_COMMITTER_* in reflog' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
test_commit custom-reflog-test &&
|
|
|
|
|
git push "$HTTPD_URL"/smart_custom_env/test_repo.git &&
|
|
|
|
|
git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git" \
|
|
|
|
|
log -g -1 --format="%gn <%ge>" >actual &&
|
|
|
|
|
echo "Custom User <custom@example.com>" >expect &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2012-08-27 15:25:36 +02:00
|
|
|
test_expect_success 'push over smart http with auth' '
|
|
|
|
|
cd "$ROOT_PATH/test_repo_clone" &&
|
|
|
|
|
echo push-auth-test >expect &&
|
|
|
|
|
test_commit push-auth-test &&
|
2014-01-02 08:38:35 +01:00
|
|
|
set_askpass user@host pass@host &&
|
2012-08-27 15:25:36 +02:00
|
|
|
git push "$HTTPD_URL"/auth/smart/test_repo.git &&
|
|
|
|
|
git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git" \
|
|
|
|
|
log -1 --format=%s >actual &&
|
|
|
|
|
expect_askpass both user@host &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
http: prompt for credentials on failed POST
All of the smart-http GET requests go through the http_get_*
functions, which will prompt for credentials and retry if we
see an HTTP 401.
POST requests, however, do not go through any central point.
Moreover, it is difficult to retry in the general case; we
cannot assume the request body fits in memory or is even
seekable, and we don't know how much of it was consumed
during the attempt.
Most of the time, this is not a big deal; for both fetching
and pushing, we make a GET request before doing any POSTs,
so typically we figure out the credentials during the first
request, then reuse them during the POST. However, some
servers may allow a client to get the list of refs from
receive-pack without authentication, and then require
authentication when the client actually tries to POST the
pack.
This is not ideal, as the client may do a non-trivial amount
of work to generate the pack (e.g., delta-compressing
objects). However, for a long time it has been the
recommended example configuration in git-http-backend(1) for
setting up a repository with anonymous fetch and
authenticated push. This setup has always been broken
without putting a username into the URL. Prior to commit
986bbc0, it did work with a username in the URL, because git
would prompt for credentials before making any requests at
all. However, post-986bbc0, it is totally broken. Since it
has been advertised in the manpage for some time, we should
make sure it works.
Unfortunately, it is not as easy as simply calling post_rpc
again when it fails, due to the input issue mentioned above.
However, we can still make this specific case work by
retrying in two specific instances:
1. If the request is large (bigger than LARGE_PACKET_MAX),
we will first send a probe request with a single flush
packet. Since this request is static, we can freely
retry it.
2. If the request is small and we are not using gzip, then
we have the whole thing in-core, and we can freely
retry.
That means we will not retry in some instances, including:
1. If we are using gzip. However, we only do so when
calling git-upload-pack, so it does not apply to
pushes.
2. If we have a large request, the probe succeeds, but
then the real POST wants authentication. This is an
extremely unlikely configuration and not worth worrying
about.
While it might be nice to cover those instances, doing so
would be significantly more complex for very little
real-world gain. In the long run, we will be much better off
when curl learns to internally handle authentication as a
callback, and we can cleanly handle all cases that way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 15:27:15 +02:00
|
|
|
test_expect_success 'push to auth-only-for-push repo' '
|
2012-08-27 15:25:53 +02:00
|
|
|
cd "$ROOT_PATH/test_repo_clone" &&
|
|
|
|
|
echo push-half-auth >expect &&
|
|
|
|
|
test_commit push-half-auth &&
|
2014-01-02 08:38:35 +01:00
|
|
|
set_askpass user@host pass@host &&
|
2012-08-27 15:25:53 +02:00
|
|
|
git push "$HTTPD_URL"/auth-push/smart/test_repo.git &&
|
|
|
|
|
git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git" \
|
|
|
|
|
log -1 --format=%s >actual &&
|
|
|
|
|
expect_askpass both user@host &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2013-04-13 05:33:36 +02:00
|
|
|
test_expect_success 'create repo without http.receivepack set' '
|
|
|
|
|
cd "$ROOT_PATH" &&
|
|
|
|
|
git init half-auth &&
|
|
|
|
|
(
|
|
|
|
|
cd half-auth &&
|
|
|
|
|
test_commit one
|
|
|
|
|
) &&
|
|
|
|
|
git clone --bare half-auth "$HTTPD_DOCUMENT_ROOT_PATH/half-auth.git"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'clone via half-auth-complete does not need password' '
|
|
|
|
|
cd "$ROOT_PATH" &&
|
|
|
|
|
set_askpass wrong &&
|
|
|
|
|
git clone "$HTTPD_URL"/half-auth-complete/smart/half-auth.git \
|
|
|
|
|
half-auth-clone &&
|
|
|
|
|
expect_askpass none
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'push into half-auth-complete requires password' '
|
|
|
|
|
cd "$ROOT_PATH/half-auth-clone" &&
|
|
|
|
|
echo two >expect &&
|
|
|
|
|
test_commit two &&
|
2014-01-02 08:38:35 +01:00
|
|
|
set_askpass user@host pass@host &&
|
2013-04-13 05:33:36 +02:00
|
|
|
git push "$HTTPD_URL/half-auth-complete/smart/half-auth.git" &&
|
|
|
|
|
git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/half-auth.git" \
|
|
|
|
|
log -1 --format=%s >actual &&
|
|
|
|
|
expect_askpass both user@host &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2014-08-21 14:21:20 +02:00
|
|
|
test_expect_success CMDLINE_LIMIT 'push 2000 tags over http' '
|
|
|
|
|
sha1=$(git rev-parse HEAD) &&
|
|
|
|
|
test_seq 2000 |
|
|
|
|
|
sort |
|
|
|
|
|
sed "s|.*|$sha1 refs/tags/really-long-tag-name-&|" \
|
|
|
|
|
>.git/packed-refs &&
|
|
|
|
|
run_with_limited_cmdline git push --mirror
|
|
|
|
|
'
|
|
|
|
|
|
2014-09-15 23:59:00 +02:00
|
|
|
test_expect_success GPG 'push with post-receive to inspect certificate' '
|
|
|
|
|
(
|
|
|
|
|
cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
|
|
|
|
|
mkdir -p hooks &&
|
|
|
|
|
write_script hooks/post-receive <<-\EOF &&
|
|
|
|
|
# discard the update list
|
|
|
|
|
cat >/dev/null
|
|
|
|
|
# record the push certificate
|
|
|
|
|
if test -n "${GIT_PUSH_CERT-}"
|
|
|
|
|
then
|
|
|
|
|
git cat-file blob $GIT_PUSH_CERT >../push-cert
|
|
|
|
|
fi &&
|
|
|
|
|
cat >../push-cert-status <<E_O_F
|
|
|
|
|
SIGNER=${GIT_PUSH_CERT_SIGNER-nobody}
|
|
|
|
|
KEY=${GIT_PUSH_CERT_KEY-nokey}
|
|
|
|
|
STATUS=${GIT_PUSH_CERT_STATUS-nostatus}
|
signed push: allow stale nonce in stateless mode
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 <gitster@pobox.com>
2014-09-05 19:46:04 +02:00
|
|
|
NONCE_STATUS=${GIT_PUSH_CERT_NONCE_STATUS-nononcestatus}
|
|
|
|
|
NONCE=${GIT_PUSH_CERT_NONCE-nononce}
|
2014-09-15 23:59:00 +02:00
|
|
|
E_O_F
|
|
|
|
|
EOF
|
|
|
|
|
|
signed push: allow stale nonce in stateless mode
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 <gitster@pobox.com>
2014-09-05 19:46:04 +02:00
|
|
|
git config receive.certnonceseed sekrit &&
|
|
|
|
|
git config receive.certnonceslop 30
|
2014-09-15 23:59:00 +02:00
|
|
|
) &&
|
|
|
|
|
cd "$ROOT_PATH/test_repo_clone" &&
|
|
|
|
|
test_commit cert-test &&
|
|
|
|
|
git push --signed "$HTTPD_URL/smart/test_repo.git" &&
|
|
|
|
|
(
|
|
|
|
|
cd "$HTTPD_DOCUMENT_ROOT_PATH" &&
|
signed push: allow stale nonce in stateless mode
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 <gitster@pobox.com>
2014-09-05 19:46:04 +02:00
|
|
|
cat <<-\EOF &&
|
2014-09-15 23:59:00 +02:00
|
|
|
SIGNER=C O Mitter <committer@example.com>
|
|
|
|
|
KEY=13B6F51ECDDE430D
|
|
|
|
|
STATUS=G
|
signed push: allow stale nonce in stateless mode
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 <gitster@pobox.com>
2014-09-05 19:46:04 +02:00
|
|
|
NONCE_STATUS=OK
|
2014-09-15 23:59:00 +02:00
|
|
|
EOF
|
signed push: allow stale nonce in stateless mode
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 <gitster@pobox.com>
2014-09-05 19:46:04 +02:00
|
|
|
sed -n -e "s/^nonce /NONCE=/p" -e "/^$/q" push-cert
|
2014-09-15 23:59:00 +02:00
|
|
|
) >expect &&
|
|
|
|
|
test_cmp expect "$HTTPD_DOCUMENT_ROOT_PATH/push-cert-status"
|
|
|
|
|
'
|
|
|
|
|
|
2016-07-14 01:36:53 +02:00
|
|
|
test_expect_success 'push status output scrubs password' '
|
t5541: fix url scrubbing test when GPG is not set
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-20 13:32:26 +02:00
|
|
|
cd "$ROOT_PATH/test_repo_clone" &&
|
|
|
|
|
git push --porcelain \
|
|
|
|
|
"$HTTPD_URL_USER_PASS/smart/test_repo.git" \
|
|
|
|
|
+HEAD:scrub >status &&
|
2016-07-14 01:36:53 +02:00
|
|
|
# should have been scrubbed down to vanilla URL
|
|
|
|
|
grep "^To $HTTPD_URL/smart/test_repo.git" status
|
|
|
|
|
'
|
|
|
|
|
|
2018-04-21 12:10:04 +02:00
|
|
|
test_expect_success 'colorize errors/hints' '
|
|
|
|
|
cd "$ROOT_PATH"/test_repo_clone &&
|
|
|
|
|
test_must_fail git -c color.transport=always -c color.advice=always \
|
|
|
|
|
-c color.push=always \
|
|
|
|
|
push origin origin/master^:master 2>act &&
|
|
|
|
|
test_decode_color <act >decoded &&
|
|
|
|
|
test_i18ngrep "<RED>.*rejected.*<RESET>" decoded &&
|
|
|
|
|
test_i18ngrep "<RED>error: failed to push some refs" decoded &&
|
|
|
|
|
test_i18ngrep "<YELLOW>hint: " decoded &&
|
|
|
|
|
test_i18ngrep ! "^hint: " decoded
|
|
|
|
|
'
|
|
|
|
|
|
2009-10-31 01:47:47 +01:00
|
|
|
stop_httpd
|
|
|
|
|
test_done
|