All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.