Stefan Beller [off-list ref] writes:
When using non-builtin protocols relying on a transport helper
(such as http), push options are not propagated to the helper.
Fix this by propagating the push options to the transport helper and
The description up to this point is VERY readable and sensible. But
that makes the title sound a bit strange. I read it as if it were
saying "stateless case can never support push-options so fail if the
caller attempts to use one", but that does not seem to be what is
going on.
adding a test that push options using http fail properly.
Sounds sensible. What end-user visible effect does this fix have?
IOW, what feature do we use "push-option" for?
Ahh, OK, so you need to describe that there are two issues in order
to be understood by the readers:
(1) the helper protocol does not propagate push-option
(2) the http helper is not prepared to handle push-option
You fix (1), and you take advantage of the fact (2) to ensure that
(1) is fixed in the new test.
With such an understanding, the title makes (sort of) sense and you
wouldn't have to be asked "what end-user visible effect/benefit does
this have?"
+'option push-option <c-string>::
+ Transmit this push option.
+
There is no "c-string" in the current documentation used or
defined. The closest thing I found is
... that field will be quoted in the manner of a C string ...
in git-status page, but I do not think you send the value for an
push-option after running quote_c_style(), so I am puzzled.
I'd rather see 'option push-option <string>' as the bullet item, and
in its description say how arbitrary values (if you allow them, that
is) can be used, e.g. "Transmit <string> encoded in such and such
way a the value of the push-option".
On Wed, Feb 8, 2017 at 10:11 AM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
When using non-builtin protocols relying on a transport helper
(such as http), push options are not propagated to the helper.
Fix this by propagating the push options to the transport helper and
The description up to this point is VERY readable and sensible. But
that makes the title sound a bit strange.
Yes, the title was there first and then I massaged the commit message
until it was readable. Originally I thought the issue is with stateless
protocols, but that is wrong. The underlying issue is just the transport
helper communication lacking.
I read it as if it were
saying "stateless case can never support push-options so fail if the
caller attempts to use one", but that does not seem to be what is
going on.
Indeed the subject is wrong.
quoted
adding a test that push options using http fail properly.
Sounds sensible. What end-user visible effect does this fix have?
IOW, what feature do we use "push-option" for?
The Gerrit world started using push options for having a better git
experience, not needing to navigate to the web UI, e.g.:
# push for review and set me as a reviewer:
git push --push-option reviewer=sbeller@google.com ssh://gerrit...
# same with http, it looks like it worked, but the push option
# never made it to the server
git push --push-option reviewer=sbeller@google.com http://gerrit...
# This patch will make the second command fail, reporting
# the http helper not supporting push options.
Ahh, OK, so you need to describe that there are two issues in order
to be understood by the readers:
(1) the helper protocol does not propagate push-option
(2) the http helper is not prepared to handle push-option
You fix (1), and you take advantage of the fact (2) to ensure that
(1) is fixed in the new test.
With such an understanding, the title makes (sort of) sense and you
wouldn't have to be asked "what end-user visible effect/benefit does
this have?"
Your analysis is correct.
quoted
+'option push-option <c-string>::
+ Transmit this push option.
+
There is no "c-string" in the current documentation used or
defined. The closest thing I found is
... that field will be quoted in the manner of a C string ...
in git-status page, but I do not think you send the value for an
push-option after running quote_c_style(), so I am puzzled.
When implementing push options, we discussed that and according to
Documentation/git-push:
The given string must not contain a NUL or LF character.
I'd rather see 'option push-option <string>' as the bullet item, and
in its description say how arbitrary values (if you allow them, that
is) can be used, e.g. "Transmit <string> encoded in such and such
way a the value of the push-option".
okay.
When using non-builtin protocols relying on a transport helper
(such as http), push options are not propagated to the helper.
The user could ask for push options and a push would seemingly succeed,
but the push options would never be transported to the server,
misleading the users expectation.
Fix this by propagating the push options to the transport helper.
This is only addressing the first issue of
(1) the helper protocol does not propagate push-option
(2) the http helper is not prepared to handle push-option
Once we fix (2), the http transport helper can make use of push options
as well, but that happens as a follow up. (1) is a bug fix, whereas (2)
is a feature, which is why we only do (1) here.
Signed-off-by: Stefan Beller <redacted>
---
Documentation/gitremote-helpers.txt | 4 ++++
t/t5545-push-options.sh | 15 +++++++++++++++
transport-helper.c | 7 +++++++
3 files changed, 26 insertions(+)
diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt
index 9e8681f9e1..23474b1eab 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -462,6 +462,10 @@ set by Git if the remote helper has the 'option' capability.
'option pushcert {'true'|'false'}::
GPG sign pushes.
+'option push-option <string>::
+ Transmit <string> as a push option. As the a push option
+ must not contain LF or NUL characters, the string is not encoded.
+
SEE ALSO
--------
linkgit:git-remote[1]diff --git a/t/t5545-push-options.sh b/t/t5545-push-options.sh
index ea813b9383..9a57a7d8f2 100755
--- a/t/t5545-push-options.sh
+++ b/t/t5545-push-options.sh
@@ -3,6 +3,8 @@
test_description='pushing to a repository using push options'
. ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-httpd.sh
+start_httpd
mk_repo_pair () {
rm -rf workbench upstream &&@@ -100,4 +102,17 @@ test_expect_success 'two push options work' '
test_cmp expect upstream/.git/hooks/post-receive.push_options
'
+test_expect_success 'push option denied properly by http remote helper' '\
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions false &&
+ git -C upstream config http.receivepack true &&
+ cp -R upstream/.git "$HTTPD_DOCUMENT_ROOT_PATH"/upstream.git &&
+ git clone "$HTTPD_URL"/smart/upstream test_http_clone &&
+ test_commit -C test_http_clone one &&
+ test_must_fail git -C test_http_clone push --push-option=asdf origin master &&
+ git -C test_http_clone push origin master
+'
+
+stop_httpd
+
test_done
diff --git a/transport-helper.c b/transport-helper.c
index 91aed35ebb..1258d6aedd 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -826,6 +826,13 @@ static void set_common_push_options(struct transport *transport,
if (set_helper_option(transport, TRANS_OPT_PUSH_CERT, "if-asked") != 0)
die("helper %s does not support --signed=if-asked", name);
}
+
+ if (flags & TRANSPORT_PUSH_OPTIONS) {
+ struct string_list_item *item;
+ for_each_string_list_item(item, transport->push_options)
+ if (set_helper_option(transport, "push-option", item->string) != 0)
+ die("helper %s does not support 'push-option'", name);
+ }
}
static int push_refs_with_push(struct transport *transport,--
2.12.0.rc0.1.g018cb5e6f4