All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org,  ps@pks.im,  jltobler@gmail.com,
	kristofferhaugsbakk@fastmail.com,
	 Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v5 2/3] receive-pack: move message generation to separate function
Date: Tue, 01 Sep 2026 09:23:42 -0700	[thread overview]
Message-ID: <xmqqbjahszxt.fsf@gitster.g> (raw)
In-Reply-To: <20260901-758-introduce-hook-v5-2-35cdc6be3cc1@gmail.com> (Karthik Nayak's message of "Tue, 01 Sep 2026 17:19:24 +0200")

Karthik Nayak <karthik.188@gmail.com> writes:

> 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.

I am torn between praising "bool detailed_report" and frowning on
it.  As the above describes, the difference in behaviour between
report() and report_v2() is if they emit details of per-command
update status, so in that sense, the word "detail" in the name of
the parameter that controls how much details the shared helper
function gives sounds very much appropriate.  On the other hand, the
difference in purpose in these two functions is which version of the
receive-pack protocol they speak, and "This parameter controls how
much detail the report contains" may tempt careless developers into
adding random new pieces of information and break existing clients.
It may be more honest to give it a name that hints that it is about
the protocol version.

Using

    enum report_version {
	receive_pack_report_v0,
	receive_pack_report_v2,
    };

might allow future extension, but it may be overkill.  I dunno.

  reply	other threads:[~2026-09-01 16:23 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18  7:55 [PATCH] hook: introduce the report hook for git-receive-pack(1) Karthik Nayak
2026-08-18 20:54 ` Junio C Hamano
2026-08-19  7:03 ` Kristoffer Haugsbakk
2026-08-19 12:11   ` Karthik Nayak
2026-08-19 14:47     ` Kristoffer Haugsbakk
2026-08-19  7:39 ` Patrick Steinhardt
2026-08-19 13:13   ` Karthik Nayak
2026-08-19 13:20     ` Patrick Steinhardt
2026-08-19 13:24       ` Karthik Nayak
2026-08-20  9:50 ` Phillip Wood
2026-08-20 15:43   ` Junio C Hamano
2026-08-21 12:51   ` Karthik Nayak
2026-08-21 13:34 ` [PATCH v2] " Karthik Nayak
2026-08-21 13:49   ` Patrick Steinhardt
2026-08-21 16:08     ` Karthik Nayak
2026-08-24  5:32       ` Patrick Steinhardt
2026-08-24  8:14         ` Karthik Nayak
2026-08-21 16:55     ` Junio C Hamano
2026-08-24 10:20 ` [PATCH v3 0/3] " Karthik Nayak
2026-08-24 10:20   ` [PATCH v3 1/3] doc: add proc-receive hook info in 'git-receive-pack.adoc' Karthik Nayak
2026-08-24 10:21   ` [PATCH v3 2/3] receive-pack: move message generation to separate function Karthik Nayak
2026-08-24 10:21   ` [PATCH v3 3/3] hook: introduce the report hook for git-receive-pack(1) Karthik Nayak
2026-08-24 15:35   ` [PATCH v3 0/3] " Junio C Hamano
2026-08-24 15:57     ` Junio C Hamano
2026-08-24 17:00       ` Patrick Steinhardt
2026-08-26  8:35     ` Karthik Nayak
2026-08-26 14:39       ` Junio C Hamano
2026-08-26 10:19 ` [PATCH v4 0/3] hook: introduce the receive-report hook Karthik Nayak
2026-08-26 10:19   ` [PATCH v4 1/3] doc: add proc-receive hook info in 'git-receive-pack.adoc' Karthik Nayak
2026-08-31  6:44     ` Patrick Steinhardt
2026-08-31 18:22       ` Karthik Nayak
2026-08-26 10:19   ` [PATCH v4 2/3] receive-pack: move message generation to separate function Karthik Nayak
2026-08-31  6:44     ` Patrick Steinhardt
2026-08-31 19:05       ` Karthik Nayak
2026-08-26 10:19   ` [PATCH v4 3/3] hook: introduce the receive-report hook Karthik Nayak
2026-08-31  6:45     ` Patrick Steinhardt
2026-09-01 15:19 ` [PATCH v5 0/3] " Karthik Nayak
2026-09-01 15:19   ` [PATCH v5 1/3] doc: add proc-receive hook info in 'git-receive-pack.adoc' Karthik Nayak
2026-09-01 15:19   ` [PATCH v5 2/3] receive-pack: move message generation to separate function Karthik Nayak
2026-09-01 16:23     ` Junio C Hamano [this message]
2026-09-02 11:23       ` Karthik Nayak
2026-09-01 15:19   ` [PATCH v5 3/3] hook: introduce the receive-report hook Karthik Nayak
2026-09-01 17:03     ` Junio C Hamano
2026-09-02 14:42       ` Karthik Nayak

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=xmqqbjahszxt.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jltobler@gmail.com \
    --cc=karthik.188@gmail.com \
    --cc=kristofferhaugsbakk@fastmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ps@pks.im \
    /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.