From: Junio C Hamano <gitster@pobox.com>
To: "Pablo Sabater" <pabloosabaterr@gmail.com>
Cc: <git@vger.kernel.org>, "Derrick Stolee" <stolee@gmail.com>
Subject: Re: [PATCH RFC 3/5] fetch-object-info: return a status instead of dying
Date: Wed, 30 Sep 2026 13:01:48 -0700 [thread overview]
Message-ID: <xmqq1paaa4pf.fsf@gitster.g> (raw)
In-Reply-To: <DLSUKMRZHHGO.HVX98MB8KLSF@gmail.com> (Pablo Sabater's message of "Wed, 30 Sep 2026 19:03:26 +0100")
"Pablo Sabater" <pabloosabaterr@gmail.com> writes:
> On Wed Sep 30, 2026 at 6:07 PM WEST, Junio C Hamano wrote:
>> Pablo Sabater <pabloosabaterr@gmail.com> writes:
>>
>>> A subsequent commit needs fetch_object_info() not to die() when the
>>> object-info capability is not enabled on the server, so that it can
>>> fall back.
>>>
>>> Make fetch_object_info() return FETCH_OBJECT_INFO_NOT_ENABLED instead
>>> of die()'ing when the server does not advertise the object-info
>>> capability, and propagate the status through the transport layer so
>>> that callers of transport_fetch_object_info() can act on it. It is now
>>> up to them whether to die() or fall back.
>>
>> It may be just me but unless the client can tell between the server
>> not supporting (i.e., they are unable to enable it even if they
>> wanted to) and not enabling (i.e., they are capable, but are not
>> willing to give it to you), it may make sense to report it as "not
>> available". "not enabled" sounds as if we know that it is the
>> latter and not the former.
>>
>> The code change looks very cleanly done.
>
> Makes sense, I'll rename it to FETCH_OBJECT_INFO_NOT_AVAILABLE.
Make it UNAVAILABLE instead.
next prev parent reply other threads:[~2026-09-30 20:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 0:21 [PATCH RFC 0/5] Add --dry-run option to git-backfill(1) Pablo Sabater
2026-09-30 0:21 ` [PATCH RFC 1/5] transport-internal: update fetch_object_info comment Pablo Sabater
2026-09-30 0:21 ` [PATCH RFC 2/5] fetch-object-info: add enum for fetch_object_info() statuses Pablo Sabater
2026-09-30 10:56 ` Karthik Nayak
2026-09-30 11:59 ` Pablo Sabater
2026-09-30 0:21 ` [PATCH RFC 3/5] fetch-object-info: return a status instead of dying Pablo Sabater
2026-09-30 17:07 ` Junio C Hamano
2026-09-30 18:03 ` Pablo Sabater
2026-09-30 20:01 ` Junio C Hamano [this message]
2026-09-30 0:21 ` [PATCH RFC 4/5] backfill: add --dry-run option Pablo Sabater
2026-09-30 11:06 ` Karthik Nayak
2026-09-30 12:19 ` Pablo Sabater
2026-09-30 0:21 ` [PATCH RFC 5/5] backfill: report total size of missing blobs in --dry-run Pablo Sabater
2026-09-30 17:17 ` Junio C Hamano
2026-09-30 18:31 ` Pablo Sabater
2026-09-30 18:14 ` [PATCH RFC 0/5] Add --dry-run option to git-backfill(1) Derrick Stolee
2026-09-30 19:06 ` Pablo Sabater
2026-09-30 20:03 ` Junio C Hamano
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=xmqq1paaa4pf.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pabloosabaterr@gmail.com \
--cc=stolee@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.