public inbox for git@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox