Taylor Blau <me@xxxxxxxxxxxx> writes: > This series is an RFC for now since I'm interested in discussing whether > or not this is a feature that people would actually want to use or not. > But if it is, I'm happy to polish this up and turn it into a > non-RFC-quality series ;-). > > In the meantime, thanks for your review! Thanks for this patch set. I can see this being used by, say, someone who wants to preserve a repo that rewinds branches all the time (the refs would need to be backed-up separately, but at least this provides a way for objects to be stored efficiently, in that reachable objects are still stored in the main repo and unreachable objects are stored in the backup with no overlap between them). I think there is at least one more alternative that should be considered, though: since the cruft pack is unlikely to have its objects "resurrected" (since the reason why they're there is because they are unreachable), it is likely that the objects that are pruned are exactly the same as those in the craft pack. So it would be more efficient to just unconditionally rename the cruft pack to the backup destination. Having said that, if there is a compelling use case for repacking even when we're moving from cruft pack to backup, the design of this patch set looks good overall. There are some minor points (e.g. the naming of the parameter "out" in patch 1), but I understand that this is an RFC and I'll wait for a non-RFC patch set before looking more closely at these things.
