Re: [PATCH 5/8] Documentation: add Packfile URIs design doc
- From
- Jonathan Tan <jonathantanmy@google.com>
- Date
- Jun 10, 2020, 18:04 UTC
- Message-ID
- <20200610180401.71146-1-jonathantanmy@google.com>
- In-Reply-To
- <xmqqeeqmg7ty.fsf@gitster.c.googlers.com>
Show 21 quoted lines
> Jonathan Tan <jonathantanmy@google.com> writes:
>
> >> > @@ -349,6 +362,9 @@ header. Most sections are sent only when the packfile is sent.
> >> > *PKT-LINE(wanted-ref LF)
> >> > wanted-ref = obj-id SP refname
> >> >
> >> > + packfile-uris = PKT-LINE("packfile-uris" LF) *packfile-uri
> >> > + packfile-uri = PKT-LINE(40*(HEXDIGIT) SP *%x20-ff LF)
> >>
> >> 40*
> >
> > I'm almost ready to send out an updated version, but have one question:
> > what do you mean by this? If you mean that I should use "obj-id"
> > instead, I didn't want to because it's not the hash of an object, but
> > the hash of a packfile.
>
> It clearly is not an object name, but it is a run of hexdigits whose
> length is the same as (hexadecimal representation of) the object name.
>
> How is "obj-id" we see above in the precontext of that hunk defined?
> Does it use 40*(HEXDIGIT), too? Yes, it's defined as such in protocol-common.txt:
obj-id = 40*(HEXDIGIT)
Show 8 quoted lines
> Do we plan to support non SHA-1 hashes > in this design in the future, and if so how? > > "We are only focused on SHA-1 hashes for now" is a perfectly > acceptable answer, and then 40* here makes 100% sense, but then we'd > need to say "for now this design only assumes SHA-1 hash" upfront, I > would think, to remind ourselves that we need to consider this part > of the system when we upgrade to SHA-256.
This will be whatever is output by index-pack after "pack\t" or "keep\t". I'll make a note in the version I'm about to send out. Yes, we'll definitely need to remind ourselves about considering this part when we upgrade.