Re: SHA256 support not experimental, or?

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 30, 2023, 16:45 UTC
Message-ID: <xmqqilb47vci.fsf@gitster.g>
In-Reply-To: <CAL3xRKfQLj7Zufy5fMMs=ykeexBn7duqFH1jZ84+WRKKOaEpFA@mail.gmail.com>

Son Luong Ngoc <sluongng@gmail.com> writes:

Show 5 quoted lines

> Build tools such as Bazel would often need to hash the content of the
> source files to build a dependency graph.  And in a FUSE setup, it would
> be ideal if the FUSE server could supply the hash via an xattr, so that
> FUSE client does not need to fetch the whole file content and only the
> metadata.

This is unrelated tangent, but the implementation of virtual filesystem on top of Git's object store will be able to give such SHA-256 hash only by computing the hash itself, if the "hash the content of the source files" has to be exactly SHA-256. Using Git repository that uses SHA-256 would *not* help.

    $ git init --object-format sha256
    $ echo hello | git hash-object --stdin
    2cf8d83d9ee29543b34a87727421fdecb7e3f3a183d337639025de576db9ebb4
    $ echo hello | sha256sum
    5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03  -

This is because the object name used by Git is not the hash of the content. It is a hash of an object header (object type and byte count) followed by its contents.

    $ printf "blob 6\0hello\n" | sha256sum
    2cf8d83d9ee29543b34a87727421fdecb7e3f3a183d337639025de576db9ebb4  -

The build systems can choose to tell FUSE server to expose the Git object names via xattr, but if it needs to see if some contents (not in FUSE) it has on hand is the same as what is stored in the FUSE server, it needs to use the "slightly modified SHA-256" that matches what Git uses. It would still be using some hash that has the same strength as underlying SHA-256, but it is *not* SHA-256.