On 2020-02-10 at 13:16:26, Han-Wen Nienhuys wrote:
> On Fri, Feb 7, 2020 at 1:16 AM brian m. carlson
> <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > + {
> > > + struct merged_table m = {
> > > + .stack = stack,
> > > + .stack_len = n,
> > > + .min = first_min,
> > > + .max = last_max,
> > > + .hash_size = SHA1_SIZE,
> >
> > This is going to cause problems with SHA-256. We'd want to write this
> > as the_hash_algo->rawsz, since it can change at runtime.
>
> As this is within the library, the hash size should be injected
> somewhere. I don't see huge problems here (the hash size could be part
> of the 'struct write_options'), but until we have properly defined how
> reftable will mark the on-disk files as SHA-256, it will only supports
> SHA1. I intend to work set the file format in motion, once this SHA1
> version is accepted into git-core.
It's not required to mark the on-disk files. A repository's storage is
either entirely SHA-1 or entirely SHA-256, except for the translation
tables. The entire marking of the repository is in the config file, and
everything in the .git directory is assumed to be in that format.
I expect full stage 4 SHA-256 support to land in the next couple of
months. Currently, the entire codebase is ready and is hash agnostic
except for a small number of remaining tests, and having reftable
support land without support for SHA-256 will be a significant
regression to that state and delay future series. So when you have a
series with tests, I'll send a patch that can be added to the series to
add SHA-256 support so we don't have that happen.
> There was one question you might be able to answer, though. Can
> repositories exist in dual hash configuration, i.e. where the ref
> database must store both SHA1 and SHA256 hashes?
No. Refs are always stored in the native format with the rest of the
repository. When we gain support for using both SHA-1 and SHA-256 to
refer to objects in the same repository, there will be either pack index
v3 or a loose object lookup table which has both and is used to
translate. We won't store both values in the ref database at once.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
