git/Documentation/git-hook.adoc, branch main

hook: reject unknown hook names in git-hook(1)

2026-03-25T21:00:48Z

Teach "git hook run" and "git hook list" to reject hook event names that are not recognized by Git. This helps catch typos such as "prereceive" when "pre-receive" was intended, since in 99% of the cases users want known (already-existing) hook names. The list of known hooks is derived from the generated hook-list.h (built from Documentation/githooks.adoc). This is why the Makefile is updated, so builtin/hook.c depends on hook-list.h. In meson the header is already a dependency for all builtins, no change required. The "--allow-unknown-hook-name" flag can be used to bypass this check. Suggested-by: Patrick Steinhardt Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

hook: show config scope in git hook list

2026-03-25T21:00:47Z

Users running "git hook list" can see which hooks are configured but have no way to tell at which config scope (local, global, system...) each hook was defined. Store the scope from ctx->kvi->scope in the single-pass config callback, then carry it through the cache to the hook structs, so we can expose it to users via the "git hook list --show-scope" flag, which mirrors the existing git config --show-scope convention. Without the flag the output is unchanged. The scope is printed as a tab-separated prefix (like "git config --show-scope"), making it unambiguously machine-parseable even when the friendly name contains spaces. Example usage: $ git hook list --show-scope pre-commit global linter local no-leaks hook from hookdir Traditional hooks from the hookdir are unaffected by --show-scope since the config scope concept does not apply to them. Suggested-by: Junio C Hamano Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

hook: make consistent use of friendly-name in docs

2026-03-25T21:00:46Z

Both `name` and `friendly-name` is being used. Standardize on `friendly-name` for consistency since name is rather generic, even when used in the hooks namespace. Suggested-by: Junio C Hamano Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

hook: add -z option to "git hook list"

2026-02-19T21:24:57Z

Add a NUL-terminate mode to git hook list, just in case hooks are configured with weird characters like newlines in their names. Suggested-by: Patrick Steinhardt Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

hook: include hooks from the config

2026-02-19T21:23:41Z

Teach the hook.[hc] library to parse configs to populate the list of hooks to run for a given event. Multiple commands can be specified for a given hook by providing "hook..command = " and "hook..event = " lines. Hooks will be started in config order of the "hook..event" lines and will be run sequentially (.jobs == 1) like before. Running the hooks in parallel will be enabled in a future patch. The "traditional" hook from the hookdir is run last, if present. A strmap cache is added to struct repository to avoid re-reading the configs on each rook run. This is useful for hooks like the ref-transaction which gets executed multiple times per process. Examples: $ git config --get-regexp "^hook\." hook.bar.command=~/bar.sh hook.bar.event=pre-commit # Will run ~/bar.sh, then .git/hooks/pre-commit $ git hook run pre-commit Signed-off-by: Emily Shaffer Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

hook: add "git hook list" command

2026-02-19T21:23:41Z

The previous commit introduced an ability to run multiple commands for hook events and next commit will introduce the ability to define hooks from configs, in addition to the "traditional" hooks from the hookdir. Introduce a new command "git hook list" to make inspecting hooks easier both for users and for the tests we will add. Further commits will expand on this, e.g. by adding a -z output mode. Signed-off-by: Emily Shaffer Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

doc: use .adoc extension for AsciiDoc files

2025-01-21T20:56:06Z

We presently use the ".txt" extension for our AsciiDoc files. While not wrong, most editors do not associate this extension with AsciiDoc, meaning that contributors don't get automatic editor functionality that could be useful, such as syntax highlighting and prose linting. It is much more common to use the ".adoc" extension for AsciiDoc files, since this helps editors automatically detect files and also allows various forges to provide rich (HTML-like) rendering. Let's do that here, renaming all of the files and updating the includes where relevant. Adjust the various build scripts and makefiles to use the new extension as well. Note that this should not result in any user-visible changes to the documentation. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano