Subject: Re: [PATCH v4 4/9] hook: add --porcelain to list command

From: Josh Steadmon <[email-masked]>
Date: Mon, 28 Sep 2020 12:29:03 -0700

On 2020.09.08 17:49, Emily Shaffer wrote:
> Teach 'git hook list --porcelain <hookname>', which prints simply the
> commands to be run in the order suggested by the config. This option is
> intended for use by user scripts, wrappers, or out-of-process Git
> commands which still want to execute hooks. For example, the following
> snippet might be added to git-send-email.perl to introduce a
> `pre-send-email` hook:
> 
>   sub pre_send_email {
>     open(my $fh, 'git hook list --porcelain pre-send-email |');
>     chomp(my @hooks = <$fh>);
>     close($fh);
> 
>     foreach $hook (@hooks) {
>             system $hook
>     }
> 
> Signed-off-by: Emily Shaffer <[email-masked]>
> ---
>  Documentation/git-hook.txt    | 13 +++++++++++--
>  builtin/hook.c                | 17 +++++++++++++----
>  t/t1360-config-based-hooks.sh | 12 ++++++++++++
>  3 files changed, 36 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/git-hook.txt b/Documentation/git-hook.txt
> index e458586e96..0854035ce2 100644
> --- a/Documentation/git-hook.txt
> +++ b/Documentation/git-hook.txt
> @@ -8,7 +8,7 @@ git-hook - Manage configured hooks
>  SYNOPSIS
>  --------
>  [verse]
> -'git hook' list <hook-name>
> +'git hook' list [--porcelain] <hook-name>
>  
>  DESCRIPTION
>  -----------
> @@ -43,11 +43,20 @@ Local config
>  COMMANDS
>  --------
>  
> -list <hook-name>::
> +list [--porcelain] <hook-name>::
>  
>  List the hooks which have been configured for <hook-name>. Hooks appear
>  in the order they should be run, and note the config scope where the relevant
>  `hook.<hook-name>.command` was specified, not the `hookcmd` (if applicable).
> ++
> +If `--porcelain` is specified, instead print the commands alone, separated by
> +newlines, for easy parsing by a script.
> +
> +OPTIONS
> +-------
> +--porcelain::
> +	With `list`, print the commands in the order they should be run,
> +	separated by newlines, for easy parsing by a script.

Rather than a hard-coded porcelain format, perhaps we could accept a
format string to allow callers to specify which items they want, for
greater forwards-compatibility?

Also, we may want a "-z / --null" option like in `git config` to delimit
by null bytes rather than newlines, in case any commands end up with
embedded newlines.