From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id F032E1F5AE for ; Thu, 13 May 2021 09:58:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232377AbhEMJ7Q (ORCPT ); Thu, 13 May 2021 05:59:16 -0400 Received: from cloud.peff.net ([104.130.231.41]:53468 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232770AbhEMJ7K (ORCPT ); Thu, 13 May 2021 05:59:10 -0400 Received: (qmail 3489 invoked by uid 109); 13 May 2021 09:57:58 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 13 May 2021 09:57:58 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 15132 invoked by uid 111); 13 May 2021 09:58:00 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 13 May 2021 05:58:00 -0400 Authentication-Results: peff.net; auth=none Date: Thu, 13 May 2021 05:57:57 -0400 From: Jeff King To: Jeff Hostetler Cc: Taylor Blau , Bagas Sanjaya , Git Users , "brian m . carlson" Subject: Re: "bad revision" fetch error when fetching missing objects from partial clones Message-ID: References: <6422f505-29c4-bee9-e28c-b77dd831c246@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, May 11, 2021 at 02:44:52PM -0400, Jeff Hostetler wrote: > > > remote: ... > > > Receiving objects: 100% (64/64), 154.49 KiB | 2.97 MiB/s, done. > > > remote: ... > > > Receiving objects: 100% (37/37), 168.35 KiB | 4.95 MiB/s, done. > > > Resolving deltas: 100% (5/5), done. > > > Resolving deltas: 100% (49/49), completed with 47 local objects. > > > fatal: bad revision 'd5e9cd36ab21839af3d116eff3221c53f6ca7fd6' > > > error: https:///bagas/gitea.git did not send all necessary > > > objects > [...] > > I'm not sure why you're getting that error, but you might > also try enabling `uploadpack.allowAnySHA1InWant` > (or one of the other "allow*SHS1InWant" values) and see if > that helps. That shouldn't be necessary these days, since the v2 protocol allows arbitrary objects to be fetched. I think it is actually a bug with pack-objects not sending the object, but it only seems to trigger with bitmaps. This works: git init repo cd repo echo content >file git add file git commit -m base git config uploadpack.allowfilter true git clone --no-local --bare --filter=blob:none . clone cd clone git fetch origin $(git rev-parse HEAD:file) But if I add a "git repack -adb" in the parent repository before the "cd clone", then I get: remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 fatal: bad revision 'd95f3ad14dee633a758d2e331151e950dd13e4ed' error: /home/peff/tmp/repo/. did not send all necessary objects So presumably this is a bug in the bitmap-aware filtering code that is not present in the regular filter-traversing code. But what really puzzles me is that the result seems totally broken. Yet the test coverage in t5310 passes, and nobody has noticed on major sites like GitHub (which supports partial clones and most certainly has bitmaps enabled). So I think it will require some digging. My _guess_ is that it has to do with the "never filter out an object that was explicitly requested" rule not being consistently followed. But we'll see. -Peff