Re: [GSoC PATCH v2 0/7] repack: add --drop-filtered to reclaim space in partial clones

From: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
Date: Aug 2, 2026, 11:28 UTC
Message-ID: <CAGWgyh91Bh-YOs9WVdbq7cEVkM0guu255GmXqJy2PhydQpNetg@mail.gmail.com>
In-Reply-To: <xmqqa4r55kpl.fsf@gitster.g>

On Sun, 2 Aug 2026 at 07:48, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

>
> Siddharth Shrimali <r.siddharth.shrimali@gmail.com> 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?