Re: [GSoC PATCH v2 0/7] repack: add --drop-filtered to reclaim space in partial clones
Siddharth Shrimali <[email protected]> Sun, 2 Aug 2026 16:58:37 +0530
| Newsgroups | org.kernel.vger.git |
|---|---|
| Message-ID | <CAGWgyh91Bh-YOs9WVdbq7cEVkM0guu255GmXqJy2PhydQpNetg@mail.gmail.com> |
On Sun, 2 Aug 2026 at 07:48, Junio C Hamano <[email protected]> wrote: > > Siddharth Shrimali <[email protected]> writes: > Doesn't it suggest that the "cull anything refetchable" feature can > gain a bit more smart? Given an object you know you fetched from a > promisor remote, are there cheap ways to determine how long you had > it in your repository? agreed, I like this a lot, recency is what the index guard was reaching for: dont drop something you are likely to want again right away. the tricky part is that droppable objects are always in packs (a lazy fetch produces a promisor pack, never a loose object, in every config i tried), and packed objects dont carry a per-object timestamp on their own. The cheap signal available is the promisor packs own mtime: since each lazy fetch writes its own pack, early on that mtime is a decent proxy for "when did this object arrive". The catch is that once a repack consolidates packs, that per-fetch granularity is lost and you only know the age of the combined pack. Git does already track per-object mtimes for cruft packs (via the .mtimes file used for --cruft-expiration), so there is precedent for age-based culling. whether something similar is worth doing for promisor objects, so age survives repacking, would be a larger discussion either way a "dont cull objects younger than <time>" rule fits the same enumerate-then-select framework as just another predicate narrowing the candidate set, so I'll note it as a promising follow-up criterion Thanks, Siddharth Shrimali > "This large blob can be refetched if we > wanted to, but we downloaded it just 20 minutes ago, so let's not > cull it just yet", or something like that, perhaps?