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 10:07:33 -0700 [thread overview]
Message-ID: <xmqqwls2brca.fsf@gitster.g> (raw)
In-Reply-To: <20260930-backfill-dryrun-v1-3-1128f247ee01@gmail.com> (Pablo Sabater's message of "Wed, 30 Sep 2026 01:21:48 +0100")
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.
next prev parent reply other threads:[~2026-09-30 17:07 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 [this message]
2026-09-30 18:03 ` Pablo Sabater
2026-09-30 20:01 ` Junio C Hamano
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=xmqqwls2brca.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox