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?