From: Emily Shaffer <emilyshaffer@google.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
"Jeff Hostetler" <jeffhost@microsoft.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Felipe Contreras" <felipe.contreras@gmail.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Eric Sunshine" <sunshine@sunshineco.com>,
"René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH v2 3/3] hook-list.h: add a generated list of hooks, like config-list.h
Date: Fri, 9 Jul 2021 13:29:57 -0700 [thread overview]
Message-ID: <YOixxZQDVDKIM8bo@google.com> (raw)
In-Reply-To: <patch-3.3-ba7f01f4f6-20210629T183325Z-avarab@gmail.com>
On Tue, Jun 29, 2021 at 08:54:02PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> Make githooks(5) the source of truth for what hooks git supports, and
> die hooks we don't know about in find_hook(). This ensures that the
> documentation and the C code's idea about existing hooks doesn't
> diverge.
>
> We still have Perl and Python code running its own hooks, but that'll
> be addressed by Emily Shaffer's upcoming "git hook run" command.
>
> This resolves a long-standing TODO item in bugreport.c of there being
> no centralized listing of hooks, and fixes a bug with the bugreport
> listing only knowing about 1/4 of the p4 hooks. It didn't know about
> the recent "reference-transaction" hook either.
>
> I have not been able to directly test the CMake change being made
> here. Since 4c2c38e800 (ci: modification of main.yml to use cmake for
> vs-build job, 2020-06-26) some of the Windows CI has a hard dependency
> on CMake, this change works there, and is to my eyes an obviously
> correct use of a pattern established in previous CMake changes,
> namely:
>
> - 061c2240b1 (Introduce CMake support for configuring Git,
> 2020-06-12)
> - 709df95b78 (help: move list_config_help to builtin/help,
> 2020-04-16)
> - 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual
> Studio solution, 2019-07-29)
>
> The LC_ALL=C is needed because at least in my locale the dash ("-") is
> ignored for the purposes of sorting, which results in a different
> order. I'm not aware of anything in git that has a hard dependency on
> the order, but e.g. the bugreport output would end up using whatever
> locale was in effect when git was compiled.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
> .gitignore | 1 +
> Makefile | 10 ++++++-
> builtin/bugreport.c | 44 ++++++-----------------------
> contrib/buildsystems/CMakeLists.txt | 7 +++++
> generate-hooklist.sh | 18 ++++++++++++
> hook.c | 19 +++++++++++++
> 6 files changed, 62 insertions(+), 37 deletions(-)
> create mode 100755 generate-hooklist.sh
>
> diff --git a/.gitignore b/.gitignore
> index 311841f9be..6be9de41ae 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -190,6 +190,7 @@
> /gitweb/static/gitweb.min.*
> /config-list.h
> /command-list.h
> +/hook-list.h
> *.tar.gz
> *.dsc
> *.deb
> diff --git a/Makefile b/Makefile
> index d155b7be21..9b811d3548 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -817,6 +817,8 @@ XDIFF_LIB = xdiff/lib.a
>
> GENERATED_H += command-list.h
> GENERATED_H += config-list.h
> +GENERATED_H += hook-list.h
> +
> .PHONY: generated-hdrs
> generated-hdrs: $(GENERATED_H)
>
> @@ -2208,7 +2210,9 @@ git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
>
> help.sp help.s help.o: command-list.h
>
> -builtin/help.sp builtin/help.s builtin/help.o: config-list.h GIT-PREFIX
> +hook.sp hook.s hook.o: hook-list.h
> +
> +builtin/help.sp builtin/help.s builtin/help.o: config-list.h hook-list.h GIT-PREFIX
> builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
> '-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
> '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
> @@ -2241,6 +2245,10 @@ command-list.h: $(wildcard Documentation/git*.txt)
> $(patsubst %,--exclude-program %,$(EXCLUDED_PROGRAMS)) \
> command-list.txt >$@+ && mv $@+ $@
>
> +hook-list.h: generate-hooklist.sh Documentation/githooks.txt
> + $(QUIET_GEN)$(SHELL_PATH) ./generate-hooklist.sh \
> + >$@+ && mv $@+ $@
> +
> SCRIPT_DEFINES = $(SHELL_PATH_SQ):$(DIFF_SQ):$(GIT_VERSION):\
> $(localedir_SQ):$(NO_CURL):$(USE_GETTEXT_SCHEME):$(SANE_TOOL_PATH_SQ):\
> $(gitwebdir_SQ):$(PERL_PATH_SQ):$(SANE_TEXT_GREP):$(PAGER_ENV):\
> diff --git a/builtin/bugreport.c b/builtin/bugreport.c
> index 941c8d5e27..a7a1fcb8a7 100644
> --- a/builtin/bugreport.c
> +++ b/builtin/bugreport.c
> @@ -4,6 +4,7 @@
> #include "help.h"
> #include "compat/compiler.h"
> #include "hook.h"
> +#include "hook-list.h"
>
>
> static void get_system_info(struct strbuf *sys_info)
> @@ -41,39 +42,7 @@ static void get_system_info(struct strbuf *sys_info)
>
> static void get_populated_hooks(struct strbuf *hook_info, int nongit)
> {
> - /*
> - * NEEDSWORK: Doesn't look like there is a list of all possible hooks;
> - * so below is a transcription of `git help hooks`. Later, this should
> - * be replaced with some programmatically generated list (generated from
> - * doc or else taken from some library which tells us about all the
> - * hooks)
> - */
> - static const char *hook[] = {
> - "applypatch-msg",
> - "pre-applypatch",
> - "post-applypatch",
> - "pre-commit",
> - "pre-merge-commit",
> - "prepare-commit-msg",
> - "commit-msg",
> - "post-commit",
> - "pre-rebase",
> - "post-checkout",
> - "post-merge",
> - "pre-push",
> - "pre-receive",
> - "update",
> - "post-receive",
> - "post-update",
> - "push-to-checkout",
> - "pre-auto-gc",
> - "post-rewrite",
> - "sendemail-validate",
> - "fsmonitor-watchman",
> - "p4-pre-submit",
> - "post-index-change",
> - };
> - int i;
> + const char **p;
>
> if (nongit) {
> strbuf_addstr(hook_info,
> @@ -81,9 +50,12 @@ static void get_populated_hooks(struct strbuf *hook_info, int nongit)
> return;
> }
>
> - for (i = 0; i < ARRAY_SIZE(hook); i++)
> - if (hook_exists(hook[i]))
> - strbuf_addf(hook_info, "%s\n", hook[i]);
> + for (p = hook_name_list; *p; p++) {
> + const char *hook = *p;
> +
> + if (hook_exists(hook))
> + strbuf_addf(hook_info, "%s\n", hook);
> + }
> }
>
> static const char * const bugreport_usage[] = {
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index a87841340e..c216940945 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -602,6 +602,13 @@ if(NOT EXISTS ${CMAKE_BINARY_DIR}/config-list.h)
> OUTPUT_FILE ${CMAKE_BINARY_DIR}/config-list.h)
> endif()
>
> +if(NOT EXISTS ${CMAKE_BINARY_DIR}/hook-list.h)
> + message("Generating hook-list.h")
> + execute_process(COMMAND ${SH_EXE} ${CMAKE_SOURCE_DIR}/generate-hooklist.sh
> + WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
> + OUTPUT_FILE ${CMAKE_BINARY_DIR}/hook-list.h)
> +endif()
> +
> include_directories(${CMAKE_BINARY_DIR})
>
> #build
> diff --git a/generate-hooklist.sh b/generate-hooklist.sh
> new file mode 100755
> index 0000000000..6d4e56d1a3
> --- /dev/null
> +++ b/generate-hooklist.sh
> @@ -0,0 +1,18 @@
> +#!/bin/sh
> +#
> +# Usage: ./generate-hooklist.sh >hook-list.h
> +
> +cat <<EOF
> +/* Automatically generated by generate-hooklist.sh */
> +
> +static const char *hook_name_list[] = {
> +EOF
> +
> +sed -n -e '/^~~~~*$/ {x; s/^.*$/ "&",/; p;}; x' \
> + <Documentation/githooks.txt |
> + LC_ALL=C sort
> +
> +cat <<EOF
> + NULL,
> +};
> +EOF
> diff --git a/hook.c b/hook.c
> index 97cd799a32..1f1db1ec9b 100644
> --- a/hook.c
> +++ b/hook.c
> @@ -1,11 +1,30 @@
> #include "cache.h"
> #include "hook.h"
> #include "run-command.h"
> +#include "hook-list.h"
> +
> +static int known_hook(const char *name)
> +{
> + const char **p;
> + size_t len = strlen(name);
> + for (p = hook_name_list; *p; p++) {
> + const char *hook = *p;
> +
> + if (!strncmp(name, hook, len) && hook[len] == '\0')
> + return 1;
> + }
> +
> + return 0;
> +}
>
> const char *find_hook(const char *name)
> {
> static struct strbuf path = STRBUF_INIT;
>
> + if (!known_hook(name))
> + die(_("the hook '%s' is not known to git, should be in hook-list.h via githooks(5)"),
> + name);
> +
I'm not sure that it's necessary to require this, to be honest. I see a
use case for wrappers to want to store and run hooks in an idiomatic
way, and doing so by instructing their users to stick in
.git/hooks/wrapper-clone (for example) and then calling 'git hook run
wrapper-clone'. That's doubly compelling in a later config-based-hooks
world where 'git hook run' gets you free multihook features like
ordering and parallelism. I will likely want to remove this when
rebasing my config-based hooks work on top of your restart.
> strbuf_reset(&path);
> strbuf_git_path(&path, "hooks/%s", name);
> if (access(path.buf, X_OK) < 0) {
> --
> 2.32.0.615.g90fb4d7369
>
next prev parent reply other threads:[~2021-07-09 20:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 10:09 [PATCH 0/3] Add a generated list of hooks in hook-list.h Ævar Arnfjörð Bjarmason
2021-06-17 10:09 ` [PATCH 1/3] hook.[ch]: move find_hook() to this new library Ævar Arnfjörð Bjarmason
2021-06-17 10:09 ` [PATCH 2/3] hook.c: add a hook_exists() wrapper and use it in bugreport.c Ævar Arnfjörð Bjarmason
2021-06-17 10:09 ` [PATCH 3/3] hook-list.h: add a generated list of hooks, like config-list.h Ævar Arnfjörð Bjarmason
2021-06-18 17:05 ` SZEDER Gábor
2021-06-18 17:50 ` Eric Sunshine
2021-06-19 6:06 ` Junio C Hamano
2021-06-20 13:53 ` Ævar Arnfjörð Bjarmason
2021-06-20 12:53 ` René Scharfe
2021-06-22 22:32 ` Johannes Schindelin
2021-06-29 0:32 ` Junio C Hamano
2021-06-29 17:53 ` René Scharfe
2021-06-29 18:53 ` [PATCH v2 0/3] Add a generated list of hooks in hook-list.h Ævar Arnfjörð Bjarmason
2021-06-29 18:54 ` [PATCH v2 1/3] hook.[ch]: move find_hook() to this new library Ævar Arnfjörð Bjarmason
2021-06-29 18:54 ` [PATCH v2 2/3] hook.c: add a hook_exists() wrapper and use it in bugreport.c Ævar Arnfjörð Bjarmason
2021-06-29 18:54 ` [PATCH v2 3/3] hook-list.h: add a generated list of hooks, like config-list.h Ævar Arnfjörð Bjarmason
2021-06-29 19:45 ` René Scharfe
2021-06-29 22:09 ` Ævar Arnfjörð Bjarmason
2021-07-09 20:29 ` Emily Shaffer [this message]
2021-07-10 9:03 ` Ævar Arnfjörð Bjarmason
2021-07-12 20:55 ` Emily Shaffer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YOixxZQDVDKIM8bo@google.com \
--to=emilyshaffer@google.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jeffhost@microsoft.com \
--cc=l.s.r@web.de \
--cc=sunshine@sunshineco.com \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.