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
Subject: Re: [PATCH 5/6] fetch: utilize rejected ref error details
Date: Wed, 14 Jan 2026 09:33:39 -0800	[thread overview]
Message-ID: <xmqqldi0f6a4.fsf@gitster.g> (raw)
In-Reply-To: <20260114-633-regression-lost-diagnostic-message-when-pushing-non-commit-objects-to-refs-heads-v1-5-f5f8b173c501@gmail.com> (Karthik Nayak's message of "Wed, 14 Jan 2026 16:40:46 +0100")

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

> In 0e358de64a (fetch: use batched reference updates, 2025-05-19),
> git-fetch(1) switched to using batched reference updates. This also
> introduced a regression wherein instead of providing detailed error
> messages for failed referenced updates, the users were provided generic
> error messages based on the error type.
>
> Similar to the previous commit, switch to using detailed error messages
> if present for failed reference updates to fix this regression.

The same question applkies as the previous step.  That is ...

> @@ -1674,9 +1674,11 @@ static void ref_transaction_rejection_handler(const char *refname,
>  			"branches"), data->remote_name);
>  		data->conflict_msg_shown = true;
>  	} else {
> -		const char *reason = ref_transaction_error_msg(err);
> -
> -		error(_("fetching ref %s failed: %s"), refname, reason);
> +		if (details)
> +			error("%s", details);
> +		else
> +			error(_("fetching ref %s failed: %s"),
> +			      refname, ref_transaction_error_msg(err));

... would "details" always carry enough information to cover
"refname" here, plus what the err code tells us?

I guess ...

> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index ce1c23684e..c69afb5a60 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -1516,7 +1516,7 @@ test_expect_success REFFILES 'existing reference lock in repo' '
>  		git remote add origin ../base &&
>  		touch refs/heads/foo.lock &&
>  		test_must_fail git fetch -f origin "refs/heads/*:refs/heads/*" 2>err &&
> -		test_grep "error: fetching ref refs/heads/foo failed: reference already exists" err &&
> +		test_grep -e "error: cannot lock ref ${SQ}refs/heads/foo${SQ}: Unable to create" -e "refs/heads/foo.lock${SQ}: File exists." err &&

... the error only talks about our local name, and when the command
is "git fetch origin refs/heads/foo:refs/remotes/origin/bar", we
only complain about refs/remotes/origin/bar without ever mentioning
refs/heads/foo on the remote side, so I think "details" has enough
information to replace the existing message here in this case.

Thanks.

  reply	other threads:[~2026-01-14 17:33 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 [this message]
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
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=xmqqldi0f6a4.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 \
    /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.