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. > 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.
