[PATCH v5 0/3] hook: introduce the receive-report hook

[Karthik Nayak <karthik.188@gmail.com>]

Introduce a new receive-report hook which kicks in after the reference
transaction is complete, but before the report is sent to the client.
The hook receives the pkt-line encoded report in its stdin and its
stdout replaces the report transferred to the user. If the hook exits
with a non-zero exit code, all references are marked as rejected.

The first patch, adds missing documentation to 'git-receive-pack.adoc'.
The second patch refactors code and the third patch contains the new
hook.

---
Changes in v5:
- Rewrote some of the commit messages and documentation.
- Renamed the function `generate_response` to `generate_report` to avoid
  ambiguity.
- We now override the cmd's error_strings, this avoids the whole
  precedence issue with the earlier series.
- Also add information about how we can override the unpack status to
  fail the push and add a corresponding test.
- Thanks to Patrick for the review!
- Junio: This causes conflict with next ('jt/receive-pack-pluggable-writes')
  similar to before, please let me know if its better for me to add that
  dependency.
- Link to v4: https://patch.msgid.link/20260826-758-introduce-hook-v4-0-6b14975ad957@gmail.com

Changes in v4:
- Change the name of the hook to be 'receive-report' to avoid ambiguity.
- Link to v3: https://patch.msgid.link/20260824-758-introduce-hook-v3-0-499526f0a062@gmail.com

Changes in v3:
- Move out addition of proc-receive hook doc to 'git-receive-pack.adoc'
  into a new commit.
- Add a new commit to move out the response generation in receive-pack
  to a new function.
- Instead of die-ing on non-zero exit code, we modify each reference to
  indicate that the hook failed.
- Instead of correctly listing out the protocol, link to
  linkgit:gitprotocol-pack[5], as the protocol also differs between v1
  and v2.
- Link to v2: https://patch.msgid.link/20260821-758-introduce-hook-v2-1-e90e2f7ac2cf@gmail.com

Changes in v2:
- Modify the documentation and commit message to be more verbose.
- Add documentation to 'git-receive-pack.adoc'
- Use 'ret' as the variable name for the return code.
- Modify the test to also check for the 'remote:'.
- Link to v1: https://patch.msgid.link/20260818-758-introduce-hook-v1-1-8a8d89e65838@gmail.com

 To: git@vger.kernel.org
 CC: ps@pks.im
 CC: gitster@pobox.com
 CC: jltobler@gmail.com
 CC: kristofferhaugsbakk@fastmail.com
 CC: phillip.wood123@gmail.com

---
Karthik Nayak (3):
      doc: add proc-receive hook info in 'git-receive-pack.adoc'
      receive-pack: move message generation to separate function
      hook: introduce the receive-report hook

 Documentation/git-receive-pack.adoc |  17 +++
 Documentation/githooks.adoc         |  47 ++++++++
 builtin/receive-pack.c              | 132 +++++++++++++++------
 t/meson.build                       |   1 +
 t/t5412-receive-report-hook.sh      | 224 ++++++++++++++++++++++++++++++++++++
 5 files changed, 384 insertions(+), 37 deletions(-)

Range-diff versus v4:

1:  6b173f391d < -:  ---------- doc: add proc-receive hook info in 'git-receive-pack.adoc'
-:  ---------- > 1:  cb32302829 doc: add proc-receive hook info in 'git-receive-pack.adoc'
2:  24e3e651ff ! 2:  ad3394490e receive-pack: move message generation to separate function
    @@ Metadata
      ## Commit message ##
         receive-pack: move message generation to separate function
     
    -    Post the reference transaction, both `report()` and `report_v2()`
    -    generate the message to be sent to the client. In v2, we also add
    -    reports for each reference if available. Since they share common code,
    -    move them to a common function. This will also help the following
    -    commit, where we will need to regenerate the message during hook
    -    failure.
    +    After git-receive-pack(1) has committed the reference updates, we call
    +    either `report()` or `report_v2()` to report to the client which of the
    +    references we have updated successfully and which updates have failed.
    +    The only difference between those two functions is that the latter also
    +    knows to provide a more detailed report about how exactly a given
    +    reference was updated.
     
    +    In the next commit we're about to add another site that wants to
    +    generate these reports. Refactor the logic into a shared function that
    +    can easily be reused.
    +
    +    Helped-by: Patrick Steinhardt <ps@pks.im>
         Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
     
      ## builtin/receive-pack.c ##
    @@ builtin/receive-pack.c: static void update_shallow_info(struct command *commands
     -static void report(struct command *commands, const char *unpack_status)
     +/*
     + * Generate the response to be sent to the client invoking 'git-receive-pack(1)'.
    -+ * For v2 protocol, set `add_reports` to true, which will also add additional
    ++ * For v2 protocol, set `detailed_report` to true, which will also add detailed
     + * report per reference update.
     + */
    -+static void generate_response(struct strbuf *buf, struct command *commands,
    -+			      const char *unpack_status, bool add_reports)
    ++static void generate_report(struct strbuf *buf, struct command *commands,
    ++			    const char *unpack_status, bool detailed_report)
      {
      	struct command *cmd;
     -	struct strbuf buf = STRBUF_INIT;
    @@ builtin/receive-pack.c: static void update_shallow_info(struct command *commands
     +		else
     +			packet_buf_write(buf, "ok %s\n", cmd->ref_name);
     +
    -+		if (!add_reports || cmd->error_string)
    ++		if (!detailed_report || cmd->error_string)
      			continue;
     -		}
     -		packet_buf_write(&buf, "ok %s\n",
    @@ builtin/receive-pack.c: static void update_shallow_info(struct command *commands
     +{
     +	struct strbuf buf = STRBUF_INIT;
     +
    -+	generate_response(&buf, commands, unpack_status, false);
    ++	generate_report(&buf, commands, unpack_status, false);
     +
     +	if (use_sideband)
     +		send_sideband(1, 1, buf.buf, buf.len, use_sideband);
    @@ builtin/receive-pack.c: static void update_shallow_info(struct command *commands
     +{
     +	struct strbuf buf = STRBUF_INIT;
     +
    -+	generate_response(&buf, commands, unpack_status, true);
    ++	generate_report(&buf, commands, unpack_status, true);
      
      	if (use_sideband)
      		send_sideband(1, 1, buf.buf, buf.len, use_sideband);
3:  d6c98d2693 ! 3:  a24ca1141d hook: introduce the receive-report hook
    @@ Commit message
         Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
     
      ## Documentation/git-receive-pack.adoc ##
    -@@ Documentation/git-receive-pack.adoc: requests. It handles refs whose names match the patterns defined by
    - `receive.procReceiveRefs` and executes the actual ref updates. See
    - linkgit:githooks[5] for the full protocol description.
    +@@ Documentation/git-receive-pack.adoc: commands will be executed by this hook, instead of by the internal
    + `execute_commands()` function.  This hook is responsible for updating
    + the relevant references and reporting the results back to 'receive-pack'.
      
     +RECEIVE-REPORT HOOK
     +-------------------
     +This hook is invoked by 'git-receive-pack' after all the ref updates
     +have been applied but before the report is sent to the client. The hook
     +receives the complete report in pkt-line format on stdin and its stdout
    -+replaces the report sent to the client. Allowing the hook to rewrite
    ++replaces the report sent to the client, which allows the hook to rewrite
     +the outcomes or abort the push completely. See linkgit:githooks[5] for
     +the full protocol description.
     +
    @@ Documentation/githooks.adoc: The exit status of the hook is ignored for any stat
     +fully buffered by `receive-pack` before any data is sent to the client,
     +so the hook's exit status is known before the client receives anything.
     +
    -+There are two distinct ways the hook can affect the push outcome:
    ++There are three distinct ways the hook can affect the push outcome:
    ++
    ++* To reject the push, modify the unpack status from `ok` to the required
    ++  error message. While `git-push` will fail, individual references may
    ++  still show success messages unless modified.
     +
     +* To reject individual ref updates while keeping `receive-pack` alive,
     +  rewrite the corresponding `ok <refname>` lines to
    -+  `ng <refname> <reason>` lines in the output and exit with status 0.
    ++  `ng <refname>[ <reason>]` lines in the output and exit with status 0.
     +  The client will then mark those specific refs as rejected while
     +  treating any `ok` refs as successful. The push as a whole is
     +  considered failed if any ref is `ng`, and `git push` will exit with
    @@ builtin/receive-pack.c: static int run_update_hook(struct command *cmd)
      					       const char *refname)
      {
     @@ builtin/receive-pack.c: static void update_shallow_info(struct command *commands,
    -  * Generate the response to be sent to the client invoking 'git-receive-pack(1)'.
    -  * For v2 protocol, set `add_reports` to true, which will also add additional
    -  * report per reference update.
    -+ * If `ref_error` is set, then all references will be rejected with the given
    -+ * error message.
    -  */
    - static void generate_response(struct strbuf *buf, struct command *commands,
    --			      const char *unpack_status, bool add_reports)
    -+			      const char *unpack_status, bool add_reports,
    -+			      const char *ref_error)
    - {
    - 	struct command *cmd;
    - 
    -@@ builtin/receive-pack.c: static void generate_response(struct strbuf *buf, struct command *commands,
    - 		if (cmd->error_string)
    - 			packet_buf_write(buf, "ng %s %s\n",
    - 					 cmd->ref_name, cmd->error_string);
    -+		else if (ref_error)
    -+			packet_buf_write(buf, "ng %s %s\n",
    -+					 cmd->ref_name, ref_error);
    - 		else
    - 			packet_buf_write(buf, "ok %s\n", cmd->ref_name);
    - 
    --		if (!add_reports || cmd->error_string)
    -+		if (!add_reports || cmd->error_string || ref_error)
    - 			continue;
    + 	free(ref_status);
    + }
      
    - 		for (report = cmd->report; report; report = report->next) {
    ++static void override_cmds_error(struct command *commands, const char *err)
    ++{
    ++	for (struct command *cmd = commands; cmd; cmd = cmd->next) {
    ++		cmd->error_string = err;
    ++	}
    ++}
    ++
    + /*
    +  * Generate the response to be sent to the client invoking 'git-receive-pack(1)'.
    +  * For v2 protocol, set `detailed_report` to true, which will also add detailed
     @@ builtin/receive-pack.c: static void report(struct command *commands, const char *unpack_status)
    - {
    - 	struct strbuf buf = STRBUF_INIT;
      
    --	generate_response(&buf, commands, unpack_status, false);
    -+	generate_response(&buf, commands, unpack_status, false, NULL);
    -+
    + 	generate_report(&buf, commands, unpack_status, false);
    + 
     +	if (run_receive_report_hook(&buf)) {
     +		strbuf_reset(&buf);
    -+		generate_response(&buf, commands, unpack_status, false,
    -+				  "receive-report hook failed");
    ++		override_cmds_error(commands, "receive-report hook failed");
    ++		generate_report(&buf, commands, unpack_status, false);
     +	}
    - 
    ++
      	if (use_sideband)
      		send_sideband(1, 1, buf.buf, buf.len, use_sideband);
    + 	else
     @@ builtin/receive-pack.c: static void report_v2(struct command *commands, const char *unpack_status)
    - {
    - 	struct strbuf buf = STRBUF_INIT;
      
    --	generate_response(&buf, commands, unpack_status, true);
    -+	generate_response(&buf, commands, unpack_status, true, NULL);
    -+
    + 	generate_report(&buf, commands, unpack_status, true);
    + 
     +	if (run_receive_report_hook(&buf)) {
     +		strbuf_reset(&buf);
    -+		generate_response(&buf, commands, unpack_status, true,
    -+			  "receive-report hook failed");
    ++		override_cmds_error(commands, "receive-report hook failed");
    ++		generate_report(&buf, commands, unpack_status, true);
     +	}
    - 
    ++
      	if (use_sideband)
      		send_sideband(1, 1, buf.buf, buf.len, use_sideband);
    + 	else
     
      ## t/meson.build ##
     @@ t/meson.build: integration_tests = [
    @@ t/t5412-receive-report-hook.sh (new)
     +	test_cmp expect actual
     +'
     +
    ++test_expect_success "hook can modify the unpack status" '
    ++	test_when_finished "rm -rf upstream" &&
    ++	test_when_finished "git -C workbench remote remove origin" &&
    ++
    ++	git init --bare upstream &&
    ++	git -C workbench remote add origin ../upstream &&
    ++	git -C workbench push origin $A:refs/heads/main &&
    ++
    ++	test_hook -C upstream --setup receive-report <<-\EOF &&
    ++	test-tool pkt-line unpack |
    ++	sed "s/^unpack ok$/unpack push failed due to server error/" |
    ++	test-tool pkt-line pack
    ++	EOF
    ++
    ++	test_must_fail git -C workbench push origin $B:refs/heads/main >out 2>&1 &&
    ++	test_grep "error: remote unpack failed: push failed due to server error" out &&
    ++	make_user_friendly_and_stable_output <out >actual &&
    ++	cat >expect <<-\EOF &&
    ++	To ../upstream
    ++	   <COMMIT-A>..<COMMIT-B>  <COMMIT-B> -> main
    ++	EOF
    ++	test_cmp expect actual
    ++'
    ++
     +test_expect_success "hook can report a custom failure message" '
     +	test_when_finished "rm -rf upstream" &&
     +	test_when_finished "git -C workbench remote remove origin" &&

---
base-commit: 11c6700f10234578d10523faf35656ca491425c9
change-id: 20260812-758-introduce-hook-5b3af9f1a7e8


Thanks
- Karthik