git/hash.h, branch jch

object-name: simplify computing common prefixes

2026-03-20T20:16:42Z

The function `extend_abbrev_len()` computes the length of common hex characters between two object IDs. This is done by: - Making the caller provide the `hex` string for the needle object ID. - Comparing every hex position of the haystack object ID with `get_hex_char_from_oid()`. Turning the binary representation into hex first is roundabout though: we can simply compare the binary representation and give some special attention to the final nibble. Introduce a new function `oid_common_prefix_hexlen()` that does exactly this and refactor the code to use the new function. This allows us to drop the `struct min_abbrev_data::hex` field. Furthermore, this function will be used in by some other callsites in subsequent commits. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

hash: expose hash context functions to Rust

2026-02-08T01:41:02Z

We'd like to be able to hash our data in Rust using the same contexts as in C. However, we need our helper functions to not be inline so they can be linked into the binary appropriately. In addition, to avoid managing memory manually and since we don't know the size of the hash context structure, we want to have simple alloc and free functions we can use to make sure a context can be easily dynamically created. Expose the helper functions and create alloc, free, and init functions we can call. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

hash: add a function to look up hash algo structs

2026-02-08T01:41:01Z

In C, it's easy for us to look up a hash algorithm structure by its offset by simply indexing the hash_algos array. However, in Rust, we sometimes need a pointer to pass to a C function, but we have our own hash algorithm abstraction. To get one from the other, let's provide a simple function that looks up the C structure from the offset and expose it in Rust. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

hash: use uint32_t for object_id algorithm

2026-02-08T01:41:01Z

We currently use an int for this value, but we'll define this structure from Rust in a future commit and we want to ensure that our data types are exactly identical. To make that possible, use a uint32_t for the hash algorithm. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'bc/use-sha256-by-default-in-3.0'

2025-07-21T16:14:25Z

Prepare to flip the default hash function to SHA-256. * bc/use-sha256-by-default-in-3.0: Enable SHA-256 by default in breaking changes mode help: add a build option for default hash t5300: choose the built-in hash outside of a repo t4042: choose the built-in hash outside of a repo t1007: choose the built-in hash outside of a repo t: default to compile-time default hash if not set setup: use the default algorithm to initialize repo format Use legacy hash for legacy formats builtin: use default hash when outside a repository hash: add a constant for the legacy hash algorithm hash: add a constant for the default hash algorithm

Enable SHA-256 by default in breaking changes mode

2025-07-01T21:58:26Z

Our document on breaking changes indicates that we intend to default to SHA-256 in Git 3.0. Since most people choose the default option, this is an important security upgrade to our defaults. To allow people to test this case, when WITH_BREAKING_CHANGES is set in the configuration, build Git with SHA-256 as the default hash. Update the testsuite to use the build options information to automatically choose the right value. Note that if the command substitution for GIT_TEST_BUILTIN_HASH fails, so does the testsuite—and quite spectacularly at that. Thus, the case where the Git binary is somehow subtly broken will not go undetected. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

hash: add a constant for the legacy hash algorithm

2025-07-01T21:58:23Z

We have a a variety of uses of GIT_HASH_SHA1 littered throughout our code. Some of these really mean to represent specifically SHA-1, but some actually represent the original hash algorithm used in Git which is implied by older, legacy formats and protocols which do not contain hash information. For instance, the bundle v1 and v2 formats do not contain hash algorithm information, and thus SHA-1 is implied by the use of these formats. Add a constant for documentary purposes which indicates this value. It will always be the same as SHA-1, since this is an essential part of these formats, but its use indicates this particular reason and not any other reason why SHA-1 might be used. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

hash: add a constant for the default hash algorithm

2025-07-01T21:58:23Z

Right now, SHA-1 is the default hash algorithm in Git. However, this may change in the future. We have many places in our code that use the SHA-1 constant to indicate the default hash if none is specified, but it will end up being more practical to specify this explicitly and clearly using a constant for whatever the default hash algorithm is. Then, if we decide to change it in the future, we can simply replace the constant representing the default with a new value. For these reasons, introduce GIT_HASH_DEFAULT to represent the default hash algorithm. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

object-name: make get_oid quietly return an error

2025-06-12T20:32:17Z

A reasonable person looking at the signature and usage of get_oid and friends might conclude that in the event of an error, it always returns -1. However, this is not the case. Instead, get_oid_basic dies if we go too far back into the history of a reflog (or, when quiet, simply exits). This is not especially useful, since in many cases, we might want to handle this error differently. Let's add a flag here to make it just return -1 like elsewhere in these code paths. Note that we cannot make this behavior the default, since we have many other codepaths that rely on the existing behavior, including in tests. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'jt/help-sha-backend-info-in-build-options'

2025-04-16T20:54:20Z

"git help --build-options" reports SHA-1 and SHA-256 backends used in the build. * jt/help-sha-backend-info-in-build-options: help: include unsafe SHA-1 build info in version help: include SHA implementation in version info