Re: [PATCH 5/6] fetch: utilize rejected ref error details

From: Karthik Nayak <karthik.188@gmail.com>
Date: Jan 15, 2026, 15:20 UTC
Message-ID: <CAOLa=ZQ0ETE+SzRV+M-xzEQFRTjdhSMseHjwnJ314yqPw8BPYA@mail.gmail.com>
In-Reply-To: <20260114180040.GH885771@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 40 quoted lines

> On Wed, Jan 14, 2026 at 04:40:46PM +0100, Karthik Nayak wrote:
>
>> @@ -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));
>>  	}
>
> OK, so here we're writing to stderr anyway, and now we'll just give the
> more detailed data. Makes sense (though like Junio, I do wonder if the
> existing message might provide more details in some cases).
>
> BTW, I think there is still a related fallout for git-fetch. Even with
> your patch, doing this:
>
>   $ git fetch . v1.0.0:refs/heads/foo
>   From .
>    * [new tag]               v1.0.0     -> foo
>   error: cannot update ref 'refs/heads/foo': trying to write non-commit object f665776185ad074b236c00751d666da7d1977dbe to branch 'refs/heads/foo'
>
> will not put anything in the status table. Whereas in v2.50.0 and
> earlier, we get:
>
>   $ git.v2.50.0 fetch . v1.0.0:refs/heads/foo
>   error: cannot update ref 'refs/heads/foo': trying to write non-commit object f665776185ad074b236c00751d666da7d1977dbe to branch 'refs/heads/foo'
>   From .
>    ! [new tag]               v1.0.0     -> foo  (unable to update local ref)
>
> Note the "!" and the "unable to update local ref" message in the status
> table.
>
> -Peff

This one is a bit harder to crack, earlier we were getting reference update results right as we added individual updates. Now that information is only received at the end when it is committed, we just don't have that information.

One way is to delay this output until we commit everything. But we don't want to iterate over refs unnecessarily, so probably store these in a list, and then iterate over them.

I'll try and add a patch for this too. Thanks for reporting.