Re: [PATCH] push options: fail properly in the stateless case

[Junio C Hamano]

Stefan Beller  writes:

>>> +'option push-option ::
>>> + 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.

OK, so "Transmit  as a push option" is sufficient, as the
string is sent as-is.  OK.

Thanks.

Re: [PATCH] push options: fail properly in the stateless case

[Stefan Beller]

On Wed, Feb 8, 2017 at 10:11 AM, Junio C Hamano  wrote:
> Stefan Beller  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.

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.

>
>> 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=sbel...@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=sbel...@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.

>
>> +'option push-option ::
>> + 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 ' as the bullet item, and
> in its description say how arbitrary values (if you allow them, that
> is) can be used, e.g. "Transmit  encoded in such and such
> way a the value of the push-option".

okay.

Re: [PATCH] push options: fail properly in the stateless case

[Junio C Hamano]

Stefan Beller  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 ::
> + 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 ' as the bullet item, and
in its description say how arbitrary values (if you allow them, that
is) can be used, e.g. "Transmit  encoded in such and such
way a the value of the push-option".

[PATCH] push options: fail properly in the stateless case

[Stefan Beller]

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
adding a test that push options using http fail properly.

Signed-off-by: Stefan Beller 
---
 Documentation/gitremote-helpers.txt |  3 +++
 t/t5545-push-options.sh | 15 +++
 transport-helper.c  |  7 +++
 3 files changed, 25 insertions(+)

diff --git a/Documentation/gitremote-helpers.txt 
b/Documentation/gitremote-helpers.txt
index 9e8681f9e1..6145d4d8df 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -462,6 +462,9 @@ set by Git if the remote helper has the 'option' capability.
 'option pushcert {'true'|'false'}::
GPG sign pushes.
 
+'option push-option ::
+   Transmit this push option.
+
 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