git/help.c, branch v2.51.2

config: drop `git_config_get_string()` wrapper

2025-07-23T15:15:19Z

In 036876a1067 (config: hide functions using `the_repository` by default, 2024-08-13) we have moved around a bunch of functions in the config subsystem that depend on `the_repository`. Those function have been converted into mere wrappers around their equivalent function that takes in a repository as parameter, and the intent was that we'll eventually remove those wrappers to make the dependency on the global repository variable explicit at the callsite. Follow through with that intent and remove `git_config_get_string()`. All callsites are adjusted so that they use `repo_config_get_string(the_repository, ...)` instead. While some callsites might already have a repository available, this mechanical conversion is the exact same as the current situation and thus cannot cause any regression. Those sites should eventually be cleaned up in a later patch series. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: drop `git_config()` wrapper

2025-07-23T15:15:18Z

In 036876a1067 (config: hide functions using `the_repository` by default, 2024-08-13) we have moved around a bunch of functions in the config subsystem that depend on `the_repository`. Those function have been converted into mere wrappers around their equivalent function that takes in a repository as parameter, and the intent was that we'll eventually remove those wrappers to make the dependency on the global repository variable explicit at the callsite. Follow through with that intent and remove `git_config()`. All callsites are adjusted so that they use `repo_config(the_repository, ...)` instead. While some callsites might already have a repository available, this mechanical conversion is the exact same as the current situation and thus cannot cause any regression. Those sites should eventually be cleaned up in a later patch series. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'bc/use-sha256-by-default-in-3.0' into ps/config-wo-the-repository

2025-07-17T16:30:56Z

* 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

BreakingChanges: announce switch to "reftable" format

2025-07-07T13:26:21Z

The "reftable" format has come a long way and has matured nicely since it has been merged into git via 57db2a094d5 (refs: introduce reftable backend, 2024-02-07). It fixes longstanding issues that cannot be fixed with the "files" format in a backwards-compatible way and performs significantly better in many use cases. Announce that we will switch to the "reftable" format in Git 3.0 for newly created repositories and wire up the change, hidden behind the WITH_BREAKING_CHANGES preprocessor define. This switch is dependent on support in the larger Git ecosystem. Most importantly, libraries like JGit, libgit2 and Gitoxide should support the reftable backend so that we don't break all applications and tools built on top of those libraries. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

help: add a build option for default hash

2025-07-01T21:58:26Z

We'd like users to be able to determine the hash algorithm that is the builtin default in their version of Git. This is useful for troubleshooting, especially when we decide to change the default. Add an entry for the default hash in the output of git version --build-options so that users can easily access that information and include it in bug reports. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Avoid redundant conditions

2025-05-15T20:46:47Z

While `if (i <= 0) ... else if (i > 0) ...` is technically equivalent to `if (i <= 0) ... else ...`, the latter is vastly easier to read because it avoids writing out a condition that is unnecessary. Let's drop such unnecessary conditions. Pointed out by CodeQL. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

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

Merge branch 'tc/zlib-ng-fix'

2025-03-12T19:06:58Z

"git version --build-options" stopped showing zlib version by mistake due to recent refactoring, which has been corrected. * tc/zlib-ng-fix: help: print zlib-ng version number help: include git-zlib.h to print zlib version

help: print zlib-ng version number

2025-03-07T20:23:30Z

When building against zlib-ng, the header file `zlib.h` is not included, but `zlib-ng.h` is included instead. It's `zlib.h` that defines `ZLIB_VERSION` and that macro is used to print out zlib version in `git-version(1)` with `--build-options`. But when it's not defined, no version is printed. `zlib-ng.h` defines another macro: `ZLIBNG_VERSION`. Use that macro to print the zlib-ng version in `git version --build-options` when it's set. Otherwise fallback to `ZLIB_VERSION`. Signed-off-by: Toon Claes Helped-by: Patrick Steinhardt Reviewed-by: Patrick Steinhardt Signed-off-by: Junio C Hamano