diff mbox series

[2/2] docs: fix step in transition plan

Message ID 20200813224901.2652387-3-sandals@crustytoothpaste.net (mailing list archive)
State Accepted
Commit 2ae12e568b14e068cd37afdd47dd46c2be8538fe
Headers show
Series Documentation updates for SHA-256 | expand

Commit Message

brian m. carlson Aug. 13, 2020, 10:49 p.m. UTC
One of the required steps for the objectFormat extension is to implement
the loose object index.  However, without support for
compatObjectFormat, we don't even know if the loose object index is
needed, so it makes sense to move that step to the compatObjectFormat
section.  Do so.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/technical/hash-function-transition.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Martin Ă…gren Aug. 14, 2020, 12:21 p.m. UTC | #1
On Fri, 14 Aug 2020 at 00:49, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> One of the required steps for the objectFormat extension is to implement
> the loose object index.  However, without support for
> compatObjectFormat, we don't even know if the loose object index is
> needed, so it makes sense to move that step to the compatObjectFormat
> section.  Do so.

This makes sense to me. I know I thought out loud before that maybe
there's some intention here and more specifically, maybe we want to
*know* that this loose-object-idx is always there. But we'd still need
to tiptoe around it in a SHA-1 repo, so even if we'd know that all
proper SHA-256 repos have been generating such a file since day 1, that
probably wouldn't help us much in terms of implementation/fallback
strategies and whatnot.

Martin
diff mbox series

Patch

diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index 5b2db3be1e..6fd20ebbc2 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -650,7 +650,6 @@  Some initial steps can be implemented independently of one another:
 
 The first user-visible change is the introduction of the objectFormat
 extension (without compatObjectFormat). This requires:
-- implementing the loose-object-idx
 - teaching fsck about this mode of operation
 - using the hash function API (vtable) when computing object names
 - signing objects and verifying signatures
@@ -658,6 +657,7 @@  extension (without compatObjectFormat). This requires:
   repository
 
 Next comes introduction of compatObjectFormat:
+- implementing the loose-object-idx
 - translating object names between object formats
 - translating object content between object formats
 - generating and verifying signatures in the compat format