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-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 C1F2D1F66E for ; Fri, 28 Aug 2020 08:31:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728614AbgH1Ib2 (ORCPT ); Fri, 28 Aug 2020 04:31:28 -0400 Received: from cloud.peff.net ([104.130.231.41]:43404 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726834AbgH1Ib1 (ORCPT ); Fri, 28 Aug 2020 04:31:27 -0400 Received: (qmail 24120 invoked by uid 109); 28 Aug 2020 08:31:26 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Fri, 28 Aug 2020 08:31:26 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4163 invoked by uid 111); 28 Aug 2020 08:31:26 -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; Fri, 28 Aug 2020 04:31:26 -0400 Authentication-Results: peff.net; auth=none Date: Fri, 28 Aug 2020 04:31:25 -0400 From: Jeff King To: Taylor Blau Cc: Derrick Stolee , Junio C Hamano , git@vger.kernel.org Subject: Re: What's cooking in git.git (Aug 2020, #07; Thu, 27) Message-ID: <20200828083125.GA2139751@coredump.intra.peff.net> References: <20200827233454.GA3973432@coredump.intra.peff.net> <20200828003940.GA80266@syl.lan> <20200828062619.GA2100989@coredump.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200828062619.GA2100989@coredump.intra.peff.net> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Aug 28, 2020 at 02:26:19AM -0400, Jeff King wrote: > On Thu, Aug 27, 2020 at 08:39:40PM -0400, Taylor Blau wrote: > > > > >> * tb/repack-clearing-midx (2020-08-26) 1 commit > > > >> (merged to 'next' on 2020-08-27 at a465875cbb) > > > >> + builtin/repack.c: invalidate MIDX only when necessary > > [...] > > Thanks indeed. I started looking into this tonight thinking that it'd be > > an easy fix, but I think there is a deeper bug that is worth > > investigating further. > > I imagine this is part of it: > > diff --git a/builtin/repack.c b/builtin/repack.c > index f10f52779c..2cc05f968a 100644 > --- a/builtin/repack.c > +++ b/builtin/repack.c > @@ -134,7 +134,7 @@ static void remove_redundant_pack(const char *dir_name, const char *base_name) > { > struct strbuf buf = STRBUF_INIT; > struct multi_pack_index *m = get_multi_pack_index(the_repository); > - strbuf_addf(&buf, "%s.pack", base_name); > + strbuf_addf(&buf, "%s.idx", base_name); > if (m && midx_contains_pack(m, buf.buf)) > clear_midx_file(the_repository); > strbuf_insertf(&buf, 0, "%s/", dir_name); > > but maybe that is just the "easy" part you meant. Several tests still > seem to fail, which I guess is the "deeper" part. :) > > If I'm understanding midx_contains_pack() correctly, then the code > looking for ".pack" could never have matched, and we would never have > deleted a midx here. Which makes me wonder why the "repack removes > multi-pack-index when deleting packs" test ever succeeded. Sorry, this is all nonsense. I forgot about the hackery added in 013fd7ada3 (midx: check both pack and index names for containment, 2019-04-05). And anyway, the patch above is totally bogus because we need the ".pack" form in the buffer when we call unlink_pack_path(). So there's definitely something more odd going on in that failing test. -Peff