On 2020-02-10 at 13:16:26, Han-Wen Nienhuys wrote:

On Fri, Feb 7, 2020 at 1:16 AM brian m. carlson
[off-list ref] wrote:

quoted

quoted

+     {
+             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