On Wed, Feb 24, 2021 at 03:43:34PM -0800, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Let me try to follow aloud to see if I got this right. > > > > If we start from 1+1+1+2+4+32+... (similarly to the example given to > > explain 2 above, but with more larger packs---but the assumption > > here is that everything larger than 32 is already in good > > progression), depending on how many loose objects we have, the > > result of packing 1+1+1+2+4+loose might not necessarily be 9 but 100 > > (collecting too many loose objects), and the set of packs would be > > 32+... (from before the "repack -g") plus a 100-object pack, not > > 9+32+... as the above explanation for 2 suggested. Starting from > > that state, re-running "repack -g" again would then have to repack > > the packs existed before the first repack (i.e. 32+...) into one. > > In other words, the second "git repack -g" in back-to-back "git > > repack -g && git repack -g" may necessarily be a no-op. > > "... may not necessarily be a no-op" is what I should have typed here. Exactly. > > Is that what you meant by non-idempotent? > > And I think it makes sense for the repack to be non-idempotent. > Once we have packs in good progression, it is the only way to make > progress by keep rolling loose objects up into the smallest pack > until it grows larger than the geometry factor allows it to be > relative to the next smallest pack. Right again. It *would* be idempotent if we didn't push any new objects into the repository (and repacked it with the same geometric factor once more to clean up any inconsistencies after creating a pack with loose objects), which is what you'd expect. Of course, pushing new objects into the repository means that the progression will either grow (i.e., because the smallest pack in an existing progression was quite large, and so we have some space to grow smaller packs before rolling up the larger one), or it will get rolled up. Thanks, Taylor
