public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuvraj Singh Chauhan <ysinghcin@gmail.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)
Date: Mon, 23 Mar 2026 14:18:58 +0530	[thread overview]
Message-ID: <acD-esOCTH3PpK9y@ThinkPad-E14-Gen-6> (raw)
In-Reply-To: <aa8VWlv7dosrrRwv@ThinkPad-E14-Gen-6>

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

  reply	other threads:[~2026-03-23  8:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 12:13 [QUESTION] Improving disk space recovery for partial clones (GSoC 2026) Yuvraj Singh Chauhan
2026-03-09 13:46 ` Christian Couder
2026-03-09 14:22   ` Yuvraj Singh Chauhan
2026-03-09 14:47     ` Christian Couder
2026-03-09 18:45       ` Yuvraj Singh Chauhan
2026-03-23  8:48         ` Yuvraj Singh Chauhan [this message]
2026-03-24 11:04           ` Christian Couder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acD-esOCTH3PpK9y@ThinkPad-E14-Gen-6 \
    --to=ysinghcin@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox