From: Jeff King <peff@peff.net>
To: Justin Su <injustsu@gmail.com>
Cc: Jonathan Tan <jonathantanmy@google.com>, git@vger.kernel.org
Subject: Re: Fetching upstream remote fails if repo was a blobless clone
Date: Sat, 2 Aug 2025 15:55:18 -0400 [thread overview]
Message-ID: <20250802195518.GA1800293@coredump.intra.peff.net> (raw)
In-Reply-To: <20250802193110.GA1774743@coredump.intra.peff.net>
On Sat, Aug 02, 2025 at 03:31:11PM -0400, Jeff King wrote:
> Doing this:
>
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> index 0a5c8a1ac8..e01cf7238b 100644
> --- a/builtin/index-pack.c
> +++ b/builtin/index-pack.c
> @@ -262,9 +262,14 @@ static unsigned check_object(struct object *obj)
> unsigned long size;
> int type = odb_read_object_info(the_repository->objects,
> &obj->oid, &size);
> - if (type <= 0)
> + if (type <= 0) {
> + if (is_promisor_object(the_repository, &obj->oid)) {
> + obj->flags |= FLAG_CHECKED;
> + return 1;
> + }
> die(_("did not receive expected object %s"),
> oid_to_hex(&obj->oid));
> + }
> if (type != obj->type)
> die(_("object %s: expected type %s, found %s"),
> oid_to_hex(&obj->oid),
>
> makes the problem go away. But I feel like I'm probably missing
> something (and that function is rather expensive to run, though maybe
> not so bad if the alternative is crashing).
>
> +cc Jonathan Tan as the author of the code comment above for any wisdom.
And here is a minimal reproduction that doesn't depend on any other
repositories:
-- >8 --
# Server has two commits, with two blobs for file, old and new.
git init server
(
cd server
echo old >file
git add .
git commit -m old
echo new >file
git commit -am new
git config uploadpack.allowfilter true
)
# The fork has built a new tree which mentions the old file.
git clone server fork
(
cd fork
git reset --hard HEAD^
echo content >unrelated
git add .
git commit -m unrelated
)
# After our partial clone, we have the new blob (because we faulted it in to
# checkout), but not the old one (because it is buried in history).
git clone --no-local --filter=blob:none server repo
cd repo
# This will get the tree at the tip of the fork repo, which mentions old. When
# we fsck that tree, we'll see that it mentions the old blob, and expect to
# find it. But we won't due to the partial clone (though we could get it if we
# wanted from the server repo).
git -c transfer.fsckObjects=true fetch ../fork
-- >8 --
That fails with stock git now, like this:
fatal: did not receive expected object 3367afdbbf91e638efe983616377c60477cc6612
fatal: index-pack failed
but succeeds with the patch above.
-Peff
prev parent reply other threads:[~2025-08-02 19:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-01 9:30 Fetching upstream remote fails if repo was a blobless clone Justin Su
2025-08-02 9:32 ` Jeff King
2025-08-02 18:02 ` Justin Su
2025-08-02 18:28 ` Justin Su
2025-08-02 19:31 ` Jeff King
2025-08-02 19:55 ` Jeff King [this message]
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=20250802195518.GA1800293@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=injustsu@gmail.com \
--cc=jonathantanmy@google.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;
as well as URLs for NNTP newsgroup(s).