[2/2] docs: fix step in transition plan
diff mbox series

Message ID 20200813224901.2652387-3-sandals@crustytoothpaste.net
State New
Headers show
Series
  • Documentation updates for SHA-256
Related show

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

Patch
diff mbox series

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