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

From: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
Date: Jul 25, 2026, 19:23 UTC
Message-ID: <CAGWgyh_3xnVXLvBwGPTQfhBK3FzXuC50Xoy6xBN_+KQafDi-4w@mail.gmail.com>
In-Reply-To: <f9c26c07-1dde-4bb6-a919-37d5229642f5@gmail.com>

Hi Siddharth,

On Fri, 24 Jul 2026 at 00:56, Siddharth Asthana <siddharthasthana31@gmail.com> wrote:

> I think these matter before we present this as a real space-reclaim
> tool. Without the index guard especially, users may drop blobs and then
> immediately fetch them back on the next command that needs the worktree.

right, I will move the safety guards into v2; refuse to run mid-merge/rebase/cherry-pick, and refuse to drop blobs referenced by the current index

>
> The drop log and remote-object-info can wait. I would not block the
> next RFC round on them.

sounds good, I can pull the drop log out of the core series and keep remote-object-info as a follow-up that upgrades the remote attribution once it is available.

> On the UI, I am fine with a separate --dry-run for now (same as
> Christian). We can revisit a --drop-filtered=<mode> form later if we
> grow more drop-specific options.

i will keep the separate --dry-run for v2 and add a note to the commit message explaining the choice, so the --drop-filtered=<mode> option stays open for later without committing to it now.