[QUESTION] Improving disk space recovery for partial clones (GSoC 2026)

7 messages between Mar 9, 2026 and Mar 24, 2026, from Yuvraj Singh Chauhan, Christian Couder.

Plain Markdown or JSON for tools and agents.

Yuvraj Singh ChauhanMar 9, 2026, 12:13 UTC on lore

Hi,

I'm interested in working on the "Improve disk space recovery for partial clones" project. I am studying the codebase, particularly promisor-remote.c, builtin/backfill.c, and the partial clone documentation.

I have a question to clarify the scope and direction of the project. The project description mentions that git-backfill vs git-gc vs git-repack vs git-maintenance is still undecided. Has there been any recent discussion or consensus on this? I want to make sure my proposal aligns with the community's direction.

sincerely,

Yuvraj

Christian CouderMar 9, 2026, 13:46 UTC in reply to Yuvraj Singh Chauhan on lore

Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)

Hi Yuvraj,

On Mon, Mar 9, 2026 at 1:14 PM Yuvraj Singh Chauhan <ysinghcin@gmail.com> wrote:

Show 6 quoted lines

>
> Hi,
>
> I'm interested in working on the "Improve disk space recovery for partial clones" project.
> I am studying the codebase, particularly promisor-remote.c, builtin/backfill.c,
> and the partial clone documentation.

Thanks for your interest in Git and this project.

Show 5 quoted lines

> I have a question to clarify the scope and direction of the project.
> The project description mentions that git-backfill vs git-gc vs
> git-repack vs git-maintenance is still undecided.
> Has there been any recent discussion or consensus on this?
> I want to make sure my proposal aligns with the community's direction.

I don't think that there is a consensus on this. It seems to me that someone said that git-backfill was likely not the best command for this, but I don't remember where and when this happened. It could have been in a private discussion.

Best.

Yuvraj Singh ChauhanMar 9, 2026, 14:22 UTC in reply to Christian Couder on lore

Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)

On Mon, Mar 09, 2026 at 02:46:06PM +0100, Christian Couder wrote:

Show 24 quoted lines

> Hi Yuvraj,
> 
> On Mon, Mar 9, 2026 at 1:14 PM Yuvraj Singh Chauhan <ysinghcin@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm interested in working on the "Improve disk space recovery for partial clones" project.
> > I am studying the codebase, particularly promisor-remote.c, builtin/backfill.c,
> > and the partial clone documentation.
> 
> Thanks for your interest in Git and this project.
> 
> > I have a question to clarify the scope and direction of the project.
> > The project description mentions that git-backfill vs git-gc vs
> > git-repack vs git-maintenance is still undecided.
> > Has there been any recent discussion or consensus on this?
> > I want to make sure my proposal aligns with the community's direction.
> 
> I don't think that there is a consensus on this. It seems to me that
> someone said that git-backfill was likely not the best command for
> this, but I don't remember where and when this happened. It could have
> been in a private discussion.
> 
> Best.

So should I understand the all the different ways and create a document for the command I think would be a good fit and why. And then the community can give their opinion on it?

sincerely, Yuvraj

Christian CouderMar 9, 2026, 14:47 UTC in reply to Yuvraj Singh Chauhan on lore

Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)

On Mon, Mar 9, 2026 at 3:22 PM Yuvraj Singh Chauhan <ysinghcin@gmail.com> wrote:

> So should I understand the all the different ways and create a document for the command
> I think would be a good fit and why. And then the community can give their opinion on it?

Yes, I think that in your proposal you can start discussing how it could be introduced into the different commands. You can describe the pros and cons of the different possibilities. Then maybe some discussion will happen when we will review your proposal and perhaps that will lead to a consensus.

Yuvraj Singh ChauhanMar 9, 2026, 18:45 UTC in reply to Christian Couder on lore

Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)

I have been studying the different commands and how they work, I will put together my understanding in a pros and cons list for each command and send it asap.

Also the contributor application period starts March 16 and ends on the March 31. Can I complete my proposal for community review in between that period as well? or should I rush to write a draft version before that.

sincerely, Yuvraj

Yuvraj Singh ChauhanMar 23, 2026, 08:48 UTC in reply to Yuvraj Singh Chauhan on lore

Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)

On Tue, Mar 10, 2026 at 12:15:46AM +0530, Yuvraj Singh Chauhan wrote:

Show 9 quoted lines

> I have been studying the different commands and how they work, I will put together
> my understanding in a pros and cons list for each command and send it asap.
> 
> Also the contributor application period starts March 16 and ends on the March 31.
> Can I complete my proposal for community review in between that period as well? or
> should I rush to write a draft version before that.
> 
> sincerely,
> Yuvraj

After some studying here the four options for placement:

Option A: git backfill --evict
Remark: 'backfill' semantically means to fill in what is missing. Adding removal semantics creates confusion. Project idea has also signalled backfill is unlikely to be the right location. The traversal logic for eviction differs enough from backfill's that there wont be a well structured shared code.

Option B: git gc / git repack
Remark: gc is already complex and runs automatically. Stolee's concern, that background tools like VS Code running git blame will immediately re-download evicted blobs, which argues directly against automatic eviction. A user who runs git gc -a does not expect silent network activity.

Option C: git maintenance task
Remark: maintenance can be a long-term home for scheduled eviction, but only after the core eviction logic is stable. An idle-detection heuristic (not yet designed) would be needed before automatic eviction is safe.

Option D: git evict (standalone command)
Remark: User-driven invocation is the approach that safely addresses Stolee's re-download concern. When the user explicitly runs git evict, they have context about what they are about to lose. No background tool can trigger git evict accidentally. This placement also avoids semantic confusion and creates a clean audit surface for the community to review.

Please review so that I can create the proposed plan accordingly

sincerely, Yuvraj Singh Chauhan

Christian CouderMar 24, 2026, 11:04 UTC in reply to Yuvraj Singh Chauhan on lore

Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)

On Mon, Mar 23, 2026 at 9:49 AM Yuvraj Singh Chauhan <ysinghcin@gmail.com> wrote:

Show 8 quoted lines

>
> On Tue, Mar 10, 2026 at 12:15:46AM +0530, Yuvraj Singh Chauhan wrote:
> > I have been studying the different commands and how they work, I will put together
> > my understanding in a pros and cons list for each command and send it asap.
> >
> > Also the contributor application period starts March 16 and ends on the March 31.
> > Can I complete my proposal for community review in between that period as well? or
> > should I rush to write a draft version before that.

We prefer it when proposals are sent to the mailing list for review between one month and one week before the end of the application period, so that they are quite up-to-date with recent developments and discussions, but we hopefully still have time to review them at least once.

So you should send one soon if you haven't already.

> After some studying here the four options for placement:
>
> Option A: git backfill --evict
> Remark: 'backfill' semantically means to fill in what is missing. Adding removal semantics creates confusion. Project idea has also signalled backfill is unlikely to be the right location. The traversal logic for eviction differs enough from backfill's that there wont be a well structured shared code.

s/wont/won't/

Show 10 quoted lines

> Option B: git gc / git repack
> Remark: gc is already complex and runs automatically. Stolee's concern, that background tools like VS Code running git blame will immediately re-download evicted blobs, which argues directly against automatic eviction. A user who runs git gc -a does not expect silent network activity.
>
> Option C: git maintenance task
> Remark: maintenance can be a long-term home for scheduled eviction, but only after the core eviction logic is stable. An idle-detection heuristic (not yet designed) would be needed before automatic eviction is safe.
>
> Option D: git evict (standalone command)
> Remark: User-driven invocation is the approach that safely addresses Stolee's re-download concern. When the user explicitly runs git evict, they have context about what they are about to lose. No background tool can trigger git evict accidentally. This placement also avoids semantic confusion and creates a clean audit surface for the community to review.
>
> Please review so that I can create the proposed plan accordingly

We cannot anticipate right now without proper patches with commit messages, documentation, tests, etc what the best solution is. So you should likely add your analysis of these options to your proposal without expecting much from some of us taking a look at them now.

Thanks.