From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Martin Ågren" <martin.agren@gmail.com>,
git@vger.kernel.org, "Derrick Stolee" <stolee@gmail.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: <xmqqo8ndufli.fsf@gitster.c.googlers.com> (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" <sandals@crustytoothpaste.net> writes:
> On 2020-08-14 at 17:28:27, Junio C Hamano wrote:
>> Martin Ågren <martin.agren@gmail.com> 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 \
--in-reply-to=xmqqo8ndufli.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=martin.agren@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.