From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Eric W. Biederman" <ebiederm@gmail.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH 2/2] doc/gitremote-helpers: match object-format option docs to code
Date: Thu, 14 Mar 2024 21:21:26 +0000 [thread overview]
Message-ID: <ZfNqVowQBy47_92m@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <87ttl99e0b.fsf@gmail.froward.int.ebiederm.org>
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
On 2024-03-14 at 12:47:16, Eric W. Biederman wrote:
> That said I think a lot of think we do a lot of that today in practice
> by simply detecting the length of the hash.
That's only true for the dumb HTTP protocol. Everything else should not
do that and we specifically want to avoid doing that, since we may very
well end up with SHA-3-256 or another 256-bit hash instead of SHA-256 if
there are sufficient cryptographic advances.
In fact, if we're going to support reftables via the dumb HTTP protocol,
then we should add some sort of capability advertisement that tells the
remote side what functionality is supported, and simply specify the hash
in that format.
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2024-03-14 21:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 8:47 [RFC/PATCH 0/2] some transport-helper "option object-format" confusion Jeff King
2024-03-07 8:51 ` [PATCH 1/2] t5801: fix object-format handling in git-remote-testgit Jeff King
2024-03-07 8:56 ` [PATCH 2/2] doc/gitremote-helpers: match object-format option docs to code Jeff King
2024-03-07 22:20 ` brian m. carlson
2024-03-12 7:45 ` Jeff King
2024-03-13 21:11 ` brian m. carlson
2024-03-14 12:47 ` Eric W. Biederman
2024-03-14 21:21 ` brian m. carlson [this message]
2024-03-15 15:41 ` Eric W. Biederman
2024-03-16 6:04 ` Jeff King
2024-03-17 20:47 ` Eric W. Biederman
2024-03-18 8:49 ` Jeff King
2024-03-14 15:33 ` Junio C Hamano
2024-03-14 21:54 ` brian m. carlson
2024-03-20 9:32 ` [PATCH 0/3] some transport-helper "option object-format" confusion Jeff King
2024-03-20 9:34 ` [PATCH 1/3] transport-helper: use write helpers more consistently Jeff King
2024-03-20 9:37 ` [PATCH 2/3] transport-helper: drop "object-format <algo>" option Jeff King
2024-03-20 9:41 ` [PATCH 3/3] transport-helper: send "true" value for object-format option Jeff King
2024-03-20 17:23 ` Junio C Hamano
2024-03-20 17:05 ` [PATCH 0/3] some transport-helper "option object-format" confusion Eric W. Biederman
2024-03-27 9:48 ` Jeff King
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=ZfNqVowQBy47_92m@tapette.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=ebiederm@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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).