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

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

[Yuvraj Singh Chauhan]

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

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

[Christian Couder]

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.

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

[Yuvraj Singh Chauhan]

On Mon, Mar 09, 2026 at 02:46:06PM +0100, Christian Couder wrote:
> 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

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

[Christian Couder]

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.

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

[Yuvraj Singh Chauhan]

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

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

[Yuvraj Singh Chauhan]

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.
> 
> 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

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

[Christian Couder]

On Mon, Mar 23, 2026 at 9:49 AM Yuvraj Singh Chauhan
<ysinghcin@gmail.com> wrote:
>
> 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/

> 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.