git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4 6/6] fetch: delay user information post committing of transaction

From
Karthik Nayak <karthik.188@gmail.com>
Date
Jan 23, 2026, 14:49 UTC
Message-ID
<CAOLa=ZSLPasvFrCgKzVOq7mDXiqX9SxoOf0MZdzBXOLn73okMQ@mail.gmail.com>
In-Reply-To
<xmqqldhpmmrw.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 53 quoted lines
> 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.
>
Yup, cannot be borrowed, since those go out of scope much earlier.
Show 30 quoted lines
>> @@ -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.
Yeah, the CI also didn't show any leaks, so we should be good.
Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 13 in “refs: provide detailed error messages when using batched update”
  1. 0/6 refs: provide detailed error messages when using batched updateKarthik Nayak, Jan 22, 2026
  2. 1/6 refs: skip to next ref when current ref is rejectedKarthik Nayak, Jan 22, 2026
  3. 2/6 refs: add rejection detail to the callback functionKarthik Nayak, Jan 22, 2026
  4. 3/6 update-ref: utilize rejected error details if availableKarthik Nayak, Jan 22, 2026
  5. 4/6 fetch: utilize rejected ref error detailsKarthik Nayak, Jan 22, 2026
  6. 5/6 receive-pack: utilize rejected ref error detailsKarthik Nayak, Jan 22, 2026
  7. 6/6 fetch: delay user information post committing of transactionKarthik Nayak, Jan 22, 2026
  8. Junio C HamanoJan 22, 2026
  9. Karthik NayakJan 23, 2026
  10. Junio C HamanoJan 23, 2026
  11. Karthik NayakJan 25, 2026
  12. Phillip WoodJan 23, 2026
  13. Karthik NayakJan 23, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.