| Message ID | 20200513005424.81369-12-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | SHA-256 part 2/3: protocol functionality | expand |
On Wed, 13 May 2020 at 02:58, brian m. carlson <sandals@crustytoothpaste.net> wrote: > > Detect when the server doesn't support our hash algorithm and abort. > + if (!server_supports_hash(the_hash_algo->name, &object_format_supported)) > + die(_("the receiving end does not support this repository's hash algorithm")); I suppose this isn't the long-term wanted behavior? Would this be where we would later learn to realize that "oh, crap, we need to convert/translate on the fly"? > @@ -428,6 +432,8 @@ int send_pack(struct send_pack_args *args, > strbuf_addstr(&cap_buf, " atomic"); > if (use_push_options) > strbuf_addstr(&cap_buf, " push-options"); > + if (object_format_supported) > + strbuf_addf(&cap_buf, " object-format=%s", the_hash_algo->name); This isn't advertised in the log message: If we do detect support, go on to reply with our choice of object format / hash algo name. Martin
On 2020-05-13 at 19:41:15, Martin Ågren wrote: > On Wed, 13 May 2020 at 02:58, brian m. carlson > <sandals@crustytoothpaste.net> wrote: > > > > Detect when the server doesn't support our hash algorithm and abort. > > > + if (!server_supports_hash(the_hash_algo->name, &object_format_supported)) > > + die(_("the receiving end does not support this repository's hash algorithm")); > > I suppose this isn't the long-term wanted behavior? Would this be where > we would later learn to realize that "oh, crap, we need to > convert/translate on the fly"? Yes, this would be the point at which we'd decide whether we could support the remote side's algorithm and decide to rewrite objects. We might still fail, such as if we're SHA-256 only without a lookup table and the remote side is SHA-1, but theoretically we'd do the conversion here. > > @@ -428,6 +432,8 @@ int send_pack(struct send_pack_args *args, > > strbuf_addstr(&cap_buf, " atomic"); > > if (use_push_options) > > strbuf_addstr(&cap_buf, " push-options"); > > + if (object_format_supported) > > + strbuf_addf(&cap_buf, " object-format=%s", the_hash_algo->name); > > This isn't advertised in the log message: If we do detect support, go on > to reply with our choice of object format / hash algo name. I'll update the message.
diff --git a/send-pack.c b/send-pack.c index d1b7edc995..fb037568a9 100644 --- a/send-pack.c +++ b/send-pack.c @@ -362,6 +362,7 @@ int send_pack(struct send_pack_args *args, int atomic_supported = 0; int use_push_options = 0; int push_options_supported = 0; + int object_format_supported = 0; unsigned cmds_sent = 0; int ret; struct async demux; @@ -388,6 +389,9 @@ int send_pack(struct send_pack_args *args, if (server_supports("push-options")) push_options_supported = 1; + if (!server_supports_hash(the_hash_algo->name, &object_format_supported)) + die(_("the receiving end does not support this repository's hash algorithm")); + if (args->push_cert != SEND_PACK_PUSH_CERT_NEVER) { int len; push_cert_nonce = server_feature_value("push-cert", &len); @@ -428,6 +432,8 @@ int send_pack(struct send_pack_args *args, strbuf_addstr(&cap_buf, " atomic"); if (use_push_options) strbuf_addstr(&cap_buf, " push-options"); + if (object_format_supported) + strbuf_addf(&cap_buf, " object-format=%s", the_hash_algo->name); if (agent_supported) strbuf_addf(&cap_buf, " agent=%s", git_user_agent_sanitized());
Detect when the server doesn't support our hash algorithm and abort. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> --- send-pack.c | 6 ++++++ 1 file changed, 6 insertions(+)