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,  peff@peff.net,  newren@gmail.com,
	phillip.wood123@gmail.com
Subject: Re: [PATCH v4 6/6] fetch: delay user information post committing of transaction
Date: Thu, 22 Jan 2026 12:10:27 -0800	[thread overview]
Message-ID: <xmqqldhpmmrw.fsf@gitster.g> (raw)
In-Reply-To: <20260122-633-regression-lost-diagnostic-message-when-pushing-non-commit-objects-to-refs-heads-v4-6-2ddba0832440@gmail.com> (Karthik Nayak's message of "Thu, 22 Jan 2026 13:05:00 +0100")

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

> +struct ref_update_display_info {
> +	bool failed;
> +	char success_code;
> +	char fail_code;
> +	const char *summary;
> +	const char *fail_detail;
> +	const char *success_detail;
> +	const char *ref;
> +	const char *remote;
> +	struct object_id old_oid;
> +	struct object_id new_oid;
> +};
> +
> +struct ref_update_display_info_array {
> +	struct ref_update_display_info *info;
> +	size_t alloc, nr;
> +};

OK.  The ref_update_display_info structure is full of pointers.
They are of "const char *" type, hinting that they are borrowed
pieces of memory, and there is nothing to clean inside, other than
the .info member itself?

> +static struct ref_update_display_info *ref_update_display_info_append(
> +					   struct ref_update_display_info_array *array,
> +					   char success_code,
> +					   char fail_code,
> +					   const char *summary,
> +					   const char *success_detail,
> +					   const char *fail_detail,
> +					   const char *ref,
> +					   const char *remote,
> +					   const struct object_id *old_oid,
> +					   const struct object_id *new_oid)
> +{

This helper that consumes the structure is used throughout the
patch, and relative to the previous round it got easier to read.

> +static void ref_update_display_info_free(struct ref_update_display_info *info)
> +{
> +	free((char *)info->summary);
> +	free((char *)info->success_detail);
> +	free((char *)info->fail_detail);
> +	free((char *)info->remote);
> +	free((char *)info->ref);
> +}

This answers "no" to my previous question.  These are not borrowed,
but are owned by this structure.

> @@ -1965,7 +2090,17 @@ static int do_fetch(struct transport *transport,
>  	 */
>  	if (retcode && !atomic_fetch && transaction)
>  		commit_ref_transaction(&transaction, false,
> -				       transport->remote->name, &err);
> +				       transport->remote->name,
> +				       &rejected_refs, &err);
> +
> +	for (size_t i = 0; i < display_array.nr; i++) {
> +		struct ref_update_display_info *info = &display_array.info[i];
> +
> +		if (!info->failed && strmap_contains(&rejected_refs, info->ref))
> +			ref_update_display_info_set_failed(info);
> +		ref_update_display_info_display(info, &display_state, summary_width);
> +		ref_update_display_info_free(info);
> +	}

And after a fetch finishes and we consume the display_info, we call
_free() to release the resource held there, plus ...

>  	if (retcode) {
>  		if (err.len) {
> @@ -1980,6 +2115,9 @@ static int do_fetch(struct transport *transport,
>  
>  	if (transaction)
>  		ref_transaction_free(transaction);
> +
> +	free(display_array.info);

... of course the array itself, which makes sense.

  reply	other threads:[~2026-01-22 20:10 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-14 15:40 [PATCH 0/6] refs: provide detailed error messages when using batched update Karthik Nayak
2026-01-14 15:40 ` [PATCH 1/6] refs: remove unused header Karthik Nayak
2026-01-14 17:08   ` Junio C Hamano
2026-01-15  9:50     ` Karthik Nayak
2026-01-14 15:40 ` [PATCH 2/6] refs: attach rejection details to updates Karthik Nayak
2026-01-14 17:43   ` Jeff King
2026-01-15 10:02     ` Karthik Nayak
2026-01-15 20:29       ` Jeff King
2026-01-16 17:56         ` Karthik Nayak
2026-01-14 15:40 ` [PATCH 3/6] refs: add rejection detail to the callback function Karthik Nayak
2026-01-14 17:44   ` Jeff King
2026-01-15 10:10     ` Karthik Nayak
2026-01-14 15:40 ` [PATCH 4/6] update-ref: utilize rejected error details if available Karthik Nayak
2026-01-14 17:27   ` Junio C Hamano
2026-01-14 17:55     ` Jeff King
2026-01-15 11:08       ` Karthik Nayak
2026-01-14 15:40 ` [PATCH 5/6] fetch: utilize rejected ref error details Karthik Nayak
2026-01-14 17:33   ` Junio C Hamano
2026-01-15 10:54     ` Karthik Nayak
2026-01-14 18:00   ` Jeff King
2026-01-15 15:20     ` Karthik Nayak
2026-01-14 15:40 ` [PATCH 6/6] receive-pack: " Karthik Nayak
2026-01-14 18:03   ` Jeff King
2026-01-15 15:21     ` Karthik Nayak
2026-01-14 16:45 ` [PATCH 0/6] refs: provide detailed error messages when using batched update Junio C Hamano
2026-01-16 21:27 ` [PATCH v2 0/7] " Karthik Nayak
2026-01-16 21:27   ` [PATCH v2 1/7] refs: drop unnecessary header includes Karthik Nayak
2026-01-18 12:07     ` SZEDER Gábor
2026-01-19  8:53       ` Karthik Nayak
2026-01-16 21:27   ` [PATCH v2 2/7] refs: skip to next ref when current ref is rejected Karthik Nayak
2026-01-16 21:27   ` [PATCH v2 3/7] refs: add rejection detail to the callback function Karthik Nayak
2026-01-16 21:27   ` [PATCH v2 4/7] update-ref: utilize rejected error details if available Karthik Nayak
2026-01-16 21:27   ` [PATCH v2 5/7] fetch: utilize rejected ref error details Karthik Nayak
2026-01-16 21:27   ` [PATCH v2 6/7] receive-pack: " Karthik Nayak
2026-01-16 21:27   ` [PATCH v2 7/7] fetch: delay user information post committing of transaction Karthik Nayak
2026-01-17 13:56     ` Phillip Wood
2026-01-19 16:11       ` Karthik Nayak
2026-01-20  9:59 ` [PATCH v3 0/6] refs: provide detailed error messages when using batched update Karthik Nayak
2026-01-20  9:59   ` [PATCH v3 1/6] refs: skip to next ref when current ref is rejected Karthik Nayak
2026-01-20  9:59   ` [PATCH v3 2/6] refs: add rejection detail to the callback function Karthik Nayak
2026-01-20  9:59   ` [PATCH v3 3/6] update-ref: utilize rejected error details if available Karthik Nayak
2026-01-20  9:59   ` [PATCH v3 4/6] fetch: utilize rejected ref error details Karthik Nayak
2026-01-20  9:59   ` [PATCH v3 5/6] receive-pack: " Karthik Nayak
2026-01-20  9:59   ` [PATCH v3 6/6] fetch: delay user information post committing of transaction Karthik Nayak
2026-01-21 16:21     ` Phillip Wood
2026-01-21 18:43       ` Junio C Hamano
2026-01-22  9:05       ` Karthik Nayak
2026-01-21 18:12   ` [PATCH v3 0/6] refs: provide detailed error messages when using batched update Junio C Hamano
2026-01-22 12:04 ` [PATCH v4 " Karthik Nayak
2026-01-22 12:04   ` [PATCH v4 1/6] refs: skip to next ref when current ref is rejected Karthik Nayak
2026-01-22 12:04   ` [PATCH v4 2/6] refs: add rejection detail to the callback function Karthik Nayak
2026-01-22 12:04   ` [PATCH v4 3/6] update-ref: utilize rejected error details if available Karthik Nayak
2026-01-22 12:04   ` [PATCH v4 4/6] fetch: utilize rejected ref error details Karthik Nayak
2026-01-22 12:04   ` [PATCH v4 5/6] receive-pack: " Karthik Nayak
2026-01-22 12:05   ` [PATCH v4 6/6] fetch: delay user information post committing of transaction Karthik Nayak
2026-01-22 20:10     ` Junio C Hamano [this message]
2026-01-23 14:49       ` Karthik Nayak
2026-01-23 17:57         ` Junio C Hamano
2026-01-25 18:47           ` Karthik Nayak
2026-01-23 14:41     ` Phillip Wood
2026-01-23 14:50       ` Karthik Nayak
2026-01-25 22:52 ` [PATCH v5 0/6] refs: provide detailed error messages when using batched update Karthik Nayak
2026-01-25 22:52   ` [PATCH v5 1/6] refs: skip to next ref when current ref is rejected Karthik Nayak
2026-01-25 22:52   ` [PATCH v5 2/6] refs: add rejection detail to the callback function Karthik Nayak
2026-01-25 22:52   ` [PATCH v5 3/6] update-ref: utilize rejected error details if available Karthik Nayak
2026-01-25 22:52   ` [PATCH v5 4/6] fetch: utilize rejected ref error details Karthik Nayak
2026-01-25 22:52   ` [PATCH v5 5/6] receive-pack: " Karthik Nayak
2026-01-25 22:52   ` [PATCH v5 6/6] fetch: delay user information post committing of transaction 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=xmqqldhpmmrw.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=phillip.wood123@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.