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.
> Let's eject this for now. If the bug turns out to be easier than I
> thought, I'll send the patch again, otherwise I'll send it with my
> larger series when that's ready.
It's in next, so the preferred path forward is generally to do a fix on
top. Unless it's so unsalvageable that we have to revert, but I doubt
that here.
-Peff
