user/sven/git.git/hash.h, branch origin/maint

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

Merge branch 'ps/object-wo-the-repository'

2025-04-15T20:50:15Z

The object layer has been updated to take an explicit repository instance as a parameter in more code paths. * ps/object-wo-the-repository: hash: stop depending on `the_repository` in `null_oid()` hash: fix "-Wsign-compare" warnings object-file: split out logic regarding hash algorithms delta-islands: stop depending on `the_repository` object-file-convert: stop depending on `the_repository` pack-bitmap-write: stop depending on `the_repository` pack-revindex: stop depending on `the_repository` pack-check: stop depending on `the_repository` environment: move access to "core.bigFileThreshold" into repo settings pack-write: stop depending on `the_repository` and `the_hash_algo` object: stop depending on `the_repository` csum-file: stop depending on `the_repository`

help: include unsafe SHA-1 build info in version

2025-04-07T21:39:27Z

In 06c92dafb8 (Makefile: allow specifying a SHA-1 for non-cryptographic uses, 2024-09-26), support for unsafe SHA-1 is added. Add the unsafe SHA-1 build info to `git version --build-info` and update corresponding documentation. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

help: include SHA implementation in version info

2025-04-07T21:39:26Z

When the `--build-options` flag is used with git-version(1), additional information about the built version of Git is printed. During build time, different SHA implementations may be configured, but this information is not included in the version info. Add the SHA implementations Git is built with to the version info by requiring each backend to define a SHA1_BACKEND or SHA256_BACKEND symbol as appropriate and use the value in the printed build options. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

object-name: allow skipping ambiguity checks in `get_oid()` family

2025-03-12T18:31:16Z

When reading an object ID via `get_oid_basic()` or any of its related functions we perform a check whether the object ID is ambiguous, which can be the case when a reference with the same name exists. While the check is generally helpful, there are cases where it only adds to the runtime overhead without providing much of a benefit. Add a new flag that allows us to disable the check. The flag will be used in a subsequent commit. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano