On Tue, Aug 25, 2020 at 09:55:22AM +0200, Son Luong Ngoc wrote: > Hi Taylor, > > Thanks for working on this. > > > On Aug 25, 2020, at 04:01, Taylor Blau <me@xxxxxxxxxxxx> wrote: > > > > In 525e18c04b (midx: clear midx on repack, 2018-07-12), 'git repack' > > learned to remove a multi-pack-index file if it added or removed a pack > > from the object store. > > > > This mechanism is a little over-eager, since it is only necessary to > > drop a MIDX if 'git repack' removes a pack that the MIDX references. > > Adding a pack outside of the MIDX does not require invalidating the > > MIDX, and likewise for removing a pack the MIDX does not know about. > > I wonder if its worth to trigger write_midx_file() to update the midx instead of > just removing MIDX? There's no reason that we couldn't do this, but I don't think that it's a very good idea, especially if the new 'git maintenance' command will be able to do something like this by itself. I'm hesitant to add yet another option to 'git repack', which I have always thought as a plumbing tool. That's important because callers (like 'git maintenance' or user scripts) can 'git multi-pack-index write ...' after their 'git repack' to generate a new MIDX if they want one. This becomes even trickier if 'git multi-pack-index write' were to gain new options, at which point 'git repack' would *also* have to learn those options to plumb them through. Maybe there's a legitimate case that I'm overlooking, but I don't think so. If there is, I'd be happy to come back to this, but this patch is really just focused on fixing a bug. > That is already the direction we are taking in the 'maintenance' patch series > whenever the multi-pack-index file was deemed invalid. > > Or perhaps, we can check for 'core.multiPackIndex' value (which recently is > 'true' by default) and determine whether we should remove the MIDX or rewrite > it? > > > > > Teach 'git repack' to check for this by loading the MIDX, and checking > > whether the to-be-removed pack is known to the MIDX. This requires a > > slightly odd alternation to a test in t5319, which is explained with a > > comment. > > > > Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx> Thanks for your feedback. > Cheers, > Son Luong. Thanks, Taylor
