From: Junio C Hamano <email@example.com> To: "brian m. carlson" <firstname.lastname@example.org> Cc: "Martin Ågren" <email@example.com>, firstname.lastname@example.org, "Derrick Stolee" <email@example.com> Subject: Re: [PATCH 1/5] http-protocol.txt: document SHA-256 "want"/"have" format Date: Fri, 14 Aug 2020 13:39:37 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20200814202347.GN8085@camp.crustytoothpaste.net> (brian m. carlson's message of "Fri, 14 Aug 2020 20:23:47 +0000") "brian m. carlson" <email@example.com> writes: > On 2020-08-14 at 17:28:27, Junio C Hamano wrote: >> Martin Ågren <firstname.lastname@example.org> writes: >> >> > Document that in SHA-1 repositories, we use SHA-1 for "want"s and >> > "have"s, and in SHA-256 repositories, we use SHA-256. >> >> Ehh, doesn't this directly contradict the transition plan of "on the >> wire everything will use SHA-1 version for now?" > > SHA-256 repositories interoperate currently using SHA-256 object IDs. > It was originally intended that we wouldn't update the protocol, but > that leads to much of the testsuite failing since it's impossible to > move objects from one place to another. > > If we wanted to be more pedantically correct and optimize for the > future, we could say that the values use the format negotiated by the > "object-format" protocol extension and SHA-1 otherwise. Yup. I think a reasonable evolution path is 0) everything on the wire is SHA-1 and no local operation knows SHA-256 (i.e. a few releases ago) 1) local operations are either SHA-1 or SHA-256 but not both. On the wire, only protocol for SHA-1 repositories are defined, so SHA-256 repositories cannot talk with anybody using any official protocol, but a "borked" SHA-1 protocol that naturally extends the object names width exists and SHA-256 repositories can interoperate with each other. This will be a backward compatibility nightmare, as Git from SHA-256 repository that tries to talk to SHA-1 repository will fail but without grace (i.e. the current situation). 2) on-the-wire protocol gains just one new capability to safely unleash SHA-256 repositories to talk to the wider world. The "borked" SHA-1 protocol above will become official when the object-format=sha256 capability is negotiated by both ends. At this stage, SHA-256 repositories still cannot talk with SHA-1 repositories, but at least they can talk among themselves as long as they use new-enough version of Git that knows about the new capability. 3) on-the-fly SHA-1 vs SHA-256 migration gets implemented. SHA-256 reposotories trying to talk to somebody else, after discovering that the other end lacks object-format=sha256 capability, on-the-fly converts its SHA-256 objecst to SHA-1 and vice versa. Between SHA-256 repositories, the capability above in 2) will allow native conversation with SHA-256. Reaching 3) may be a lot of work, but at least we should get to 2) to be able to safely let SHA-256 repositories to talk to the outside world (yes, I consider it OK for SHA-256 repositories talking among themselves in a private setting in the current state, and it would be a good milestone and also test towards the eventual goal of reaching 3), and with much smaller effort. Thanks.
next prev parent reply other threads:[~2020-08-14 20:39 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-13 22:48 [PATCH 0/2] Documentation updates for SHA-256 brian m. carlson 2020-08-13 22:49 ` [PATCH 1/2] docs: document SHA-256 pack and indices brian m. carlson 2020-08-14 2:26 ` Derrick Stolee 2020-08-13 22:49 ` [PATCH 2/2] docs: fix step in transition plan brian m. carlson 2020-08-14 12:21 ` Martin Ågren 2020-08-14 2:33 ` [PATCH 0/2] Documentation updates for SHA-256 Derrick Stolee 2020-08-14 4:47 ` Junio C Hamano 2020-08-14 20:20 ` brian m. carlson 2020-08-14 20:25 ` Junio C Hamano 2020-08-14 12:21 ` [PATCH 0/5] more SHA-256 documentation Martin Ågren 2020-08-14 12:21 ` [PATCH 1/5] http-protocol.txt: document SHA-256 "want"/"have" format Martin Ågren 2020-08-14 17:28 ` Junio C Hamano 2020-08-14 20:23 ` brian m. carlson 2020-08-14 20:32 ` Martin Ågren 2020-08-14 20:39 ` Junio C Hamano [this message] 2020-08-14 20:47 ` Junio C Hamano 2020-08-14 12:21 ` [PATCH 2/5] index-format.txt: document SHA-256 index format Martin Ågren 2020-08-14 12:28 ` Derrick Stolee 2020-08-14 14:05 ` Martin Ågren 2020-08-14 12:21 ` [PATCH 3/5] protocol-capabilities.txt: clarify "allow-x-sha1-in-want" re SHA-256 Martin Ågren 2020-08-14 12:31 ` Derrick Stolee 2020-08-14 14:05 ` Martin Ågren 2020-08-14 17:33 ` Junio C Hamano 2020-08-14 20:35 ` Martin Ågren 2020-08-14 20:43 ` Junio C Hamano 2020-08-14 12:21 ` [PATCH 4/5] shallow.txt: document SHA-256 shallow format Martin Ågren 2020-08-14 12:21 ` [PATCH 5/5] commit-graph-format.txt: fix "Hash Version" description Martin Ågren 2020-08-14 12:37 ` Derrick Stolee 2020-08-14 14:10 ` Martin Ågren 2020-08-14 20:28 ` [PATCH 0/5] more SHA-256 documentation brian m. carlson 2020-08-15 16:05 ` [PATCH v2 0/4] " Martin Ågren 2020-08-15 16:05 ` [PATCH v2 1/4] http-protocol.txt: document SHA-256 "want"/"have" format Martin Ågren 2020-08-15 16:06 ` [PATCH v2 2/4] index-format.txt: document SHA-256 index format Martin Ågren 2020-08-15 16:06 ` [PATCH v2 3/4] protocol-capabilities.txt: clarify "allow-x-sha1-in-want" re SHA-256 Martin Ågren 2020-08-15 16:06 ` [PATCH v2 4/4] shallow.txt: document SHA-256 shallow format Martin Ågren
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 * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 1/5] http-protocol.txt: document SHA-256 "want"/"have" format' \ /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
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 NNTP newsgroup(s).