Re: [PATCH v13 06/13] reftable: define version 2 of the spec to accomodate SHA256
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- May 20, 2020, 12:38 UTC
- Message-ID
- <CAFQ2z_PqiziTt-M+hCP4XOwgRMr2m4WEBTjwi6EPkyK6MbBoYg@mail.gmail.com>
- In-Reply-To
- <xmqq5zcrzhc7.fsf@gitster.c.googlers.com>
On Wed, May 20, 2020 at 12:32 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> > -* Near constant time verification if a SHA-1 is referred to by at least > > +* Near constant time verification if an object ID is referred to by at least > > one reference (for allow-tip-sha1-in-want). > > Good. These are called "object names", though. >
Fixed throughout.
All of the source code (libgit2, Jgit, git itself) calls this object ID (git_oid, ObjectId, struct object_id respectively), so it's a bit surprising.
Show 13 quoted lines
> > * `0x3`: symbolic reference: `varint( target_len ) target` > > > @@ -434,7 +455,7 @@ works the same as in reference blocks. > > > > Because object identifiers are abbreviated by writers to the shortest > > unique abbreviation within the reftable, obj key lengths are variable > > -between 2 and 20 bytes. Readers must compare only for common prefix > > +between 2 and 32 bytes. Readers must compare only for common prefix > > Is it allowed for a reftable file whose hash_id field says "sha1" to > use more than 20 bytes of obj key? Phrasing it like "unique prefix > of object name, no shorter than 2 bytes" would avoid the problem, I > would think.
rephrased.
> This version also adds more > > > ’
curious. I have no idea where they came from. Fixed now.
-- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado