From: Jonathan Tan <jonathantanmy@google.com>
To: git@vger.kernel.org
Cc: Jonathan Tan <jonathantanmy@google.com>, jrnieder@gmail.com
Subject: [PATCH v3 0/2] Server options when cloning
Date: Thu, 11 Apr 2019 13:30:14 -0700 [thread overview]
Message-ID: <cover.1555014408.git.jonathantanmy@google.com> (raw)
In-Reply-To: <20190405204413.93900-1-jonathantanmy@google.com>
Thanks, Jonathan Nieder, for your review.
> Thanks for writing this. I'd be in favor of making this die().
> Compare what we already do in push:
>
> if (args->push_options && !push_options_supported)
> die(_("the receiving end does not support push options"));
Thanks for pointing out what "push" does, and done.
> What happens in the case of push with protocol v0, where server options
> are supported?
They are just sent to the pre-receive and post-receive hooks, according
to the "git push" documentation. I added a mention of the push option
behavior in the 2nd commit's message.
> For example:
>
> fatal: server options require protocol version 2 or later
> hint: see protocol.version in "git help config" for more details
Thanks - used your example (except I put the hint first, since the fatal
line is fatal).
> Should this use a static to also warn only once in the tag-catchup case
> you mentioned?
Since we're dying, this is no longer needed.
Jonathan Tan (2):
transport: warn if server options are unsupported
clone: send server options when using protocol v2
Documentation/fetch-options.txt | 3 ++-
Documentation/git-clone.txt | 8 +++++++
builtin/clone.c | 6 +++++
t/t5702-protocol-v2.sh | 41 +++++++++++++++++++++++++++++++++
transport.c | 10 ++++++++
5 files changed, 67 insertions(+), 1 deletion(-)
Range-diff against v2:
1: af3cc05324 ! 1: 63049081c9 transport: warn if server options are unsupported
@@ -4,13 +4,13 @@
Server options were added in commit 5e3548ef16 ("fetch: send server
options when using protocol v2", 2018-04-24), supported only for
- protocol version 2. Add a warning if server options are specified for
- the user if a legacy protocol is used instead.
+ protocol version 2. But if the user specifies server options, and the
+ protocol version being used doesn't support them, the server options are
+ silently ignored.
- An effort is made to avoid printing the same warning more than once by
- clearing transport->server_options after the warning, but this does not
- fully avoid double-printing (for example, when backfulling tags using
- another fetch with a non-reusable transport).
+ Teach any transport users to die instead in this situation, just like
+ how "push" dies if push options are provided when the server doesn't
+ support them.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
@@ -22,10 +22,11 @@
'
+test_expect_success 'warn if using server-option with ls-remote with legacy protocol' '
-+ GIT_TEST_PROTOCOL_VERSION=0 git -c protocol.version=0 \
++ GIT_TEST_PROTOCOL_VERSION=0 test_must_fail git -c protocol.version=0 \
+ ls-remote -o hello -o world "file://$(pwd)/file_parent" master 2>err &&
+
-+ grep "Ignoring server options" err
++ grep "see protocol.version in" err &&
++ grep "server options require protocol version 2 or later" err
+'
test_expect_success 'clone with file:// using protocol v2' '
@@ -39,10 +40,11 @@
+
+ git init temp_child &&
+
-+ GIT_TEST_PROTOCOL_VERSION=0 git -C temp_child -c protocol.version=0 \
++ GIT_TEST_PROTOCOL_VERSION=0 test_must_fail git -C temp_child -c protocol.version=0 \
+ fetch -o hello -o world "file://$(pwd)/file_parent" master 2>err &&
+
-+ grep "Ignoring server options" err
++ grep "see protocol.version in" err &&
++ grep "server options require protocol version 2 or later" err
+'
+
test_expect_success 'upload-pack respects config using protocol v2' '
@@ -56,10 +58,12 @@
return 0;
}
-+static void warn_server_options_unsupported(struct transport *transport)
++static void die_if_server_options(struct transport *transport)
+{
-+ warning(_("Ignoring server options because protocol version does not support it"));
-+ transport->server_options = NULL;
++ if (!transport->server_options || !transport->server_options->nr)
++ return;
++ advise(_("see protocol.version in 'git help config' for more details"));
++ die(_("server options require protocol version 2 or later"));
+}
+
/*
@@ -69,7 +73,7 @@
break;
case protocol_v1:
case protocol_v0:
-+ warn_server_options_unsupported(transport);
++ die_if_server_options(transport);
get_remote_heads(&reader, &refs,
for_push ? REF_NORMAL : 0,
&data->extra_have,
@@ -77,7 +81,7 @@
break;
case protocol_v1:
case protocol_v0:
-+ warn_server_options_unsupported(transport);
++ die_if_server_options(transport);
refs = fetch_pack(&args, data->fd, data->conn,
refs_tmp ? refs_tmp : transport->remote_refs,
dest, to_fetch, nr_heads, &data->shallow,
2: 142c25abd2 ! 2: f59b8244eb clone: send server options when using protocol v2
@@ -12,7 +12,9 @@
"--server-option".
Explain in the documentation, both for clone and for fetch, that server
- handling of server options are server-specific.
+ handling of server options are server-specific. This is similar to
+ receive-pack's handling of push options - currently, they are just sent
+ to hooks to interpret as they see fit.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
@@ -86,7 +88,7 @@
--- a/t/t5702-protocol-v2.sh
+++ b/t/t5702-protocol-v2.sh
@@
- grep "Ignoring server options" err
+ grep "server options require protocol version 2 or later" err
'
+test_expect_success 'server-options are sent when cloning' '
@@ -103,11 +105,12 @@
+test_expect_success 'warn if using server-option with clone with legacy protocol' '
+ test_when_finished "rm -rf myclone" &&
+
-+ GIT_TEST_PROTOCOL_VERSION=0 git -c protocol.version=0 \
++ GIT_TEST_PROTOCOL_VERSION=0 test_must_fail git -c protocol.version=0 \
+ clone --server-option=hello --server-option=world \
+ "file://$(pwd)/file_parent" myclone 2>err &&
+
-+ grep "Ignoring server options" err
++ grep "see protocol.version in" err &&
++ grep "server options require protocol version 2 or later" err
+'
+
test_expect_success 'upload-pack respects config using protocol v2' '
--
2.21.0.392.gf8f6787159e-goog
next prev parent reply other threads:[~2019-04-11 20:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-05 20:44 [PATCH] clone: send server options when using protocol v2 Jonathan Tan
2019-04-06 11:57 ` Jonathan Nieder
2019-04-08 17:11 ` Jonathan Tan
2019-04-09 15:24 ` Junio C Hamano
2019-04-09 18:49 ` Jonathan Tan
2019-04-09 20:31 ` [PATCH v2 0/2] Server options when cloning Jonathan Tan
2019-04-09 20:31 ` [PATCH v2 1/2] transport: warn if server options are unsupported Jonathan Tan
2019-04-09 20:45 ` Jonathan Nieder
2019-04-10 3:51 ` Junio C Hamano
2019-04-09 20:31 ` [PATCH v2 2/2] clone: send server options when using protocol v2 Jonathan Tan
2019-04-09 20:46 ` Jonathan Nieder
2019-04-11 20:30 ` Jonathan Tan [this message]
2019-04-11 20:30 ` [PATCH v3 1/2] transport: warn if server options are unsupported Jonathan Tan
2019-04-12 5:35 ` Junio C Hamano
2019-04-11 20:30 ` [PATCH v3 2/2] clone: send server options when using protocol v2 Jonathan Tan
2019-04-12 19:51 ` [PATCH v4 0/2] Server options when cloning Jonathan Tan
2019-04-12 19:51 ` [PATCH v4 1/2] transport: die if server options are unsupported Jonathan Tan
2019-04-12 20:12 ` SZEDER Gábor
2019-04-15 4:48 ` Re* " Junio C Hamano
2019-04-15 4:54 ` Junio C Hamano
2019-04-15 9:43 ` SZEDER Gábor
2019-04-12 19:51 ` [PATCH v4 2/2] clone: send server options when using protocol v2 Jonathan Tan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1555014408.git.jonathantanmy@google.com \
--to=jonathantanmy@google.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).