public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Amisha Chhajed <amishhhaaaa@gmail.com>,
	git@vger.kernel.org, karthik nayak <karthik.188@gmail.com>,
	"jltobler@gmail.com" <jltobler@gmail.com>,
	Siddharth Asthana <siddharthasthana31@gmail.com>,
	Ayush Chandekar <ayu.chandekar@gmail.com>,
	christian.couder@gmail.com
Subject: Re: [GSOC] Discuss and Introduction: Improve disk space recovery for partial clones
Date: Wed, 25 Feb 2026 06:49:08 -0500	[thread overview]
Message-ID: <735eb76e-44a9-4f79-b769-23a3a07437ae@gmail.com> (raw)
In-Reply-To: <CAPvEtrfYtEvsxbsD2Q378R3e84DwHPPCSgaa1pQugrwchj9h8g@mail.gmail.com>

On 2/25/26 1:17 AM, Amisha Chhajed wrote:

> I am aspiring to apply for project 'Improve disk space recovery for
> partial clones',

I think this is a noble goal. Removing blobs that you don't expect to
need again would be valuable.

> I am aware of sparse-checkout and surrounding code while working on my
> first patch,
> hence i believe if we are in cone mode we can easily free up the space
> in partial clone
> for files outside of cone mode whenever user runs cleanup command, however
> figuring out what to free in non cone mode is a fairly new topic for
> me, i would love to have
> discussions surrounding this, i believe a lot inspiration about what
> we can clean can be
> derived from git gc and git maintenance.

I think you will have a larger impact if you focus on _old_ blobs that
were maybe necessary for a previous checkout of an old commit but the
paths have been updated in more recent checkouts so those blobs are
unlikely to be needed again other than for history queries.

You should keep in mind that some tools automatically populate stale
data (such as VS Code running 'git blame' in the background of every
open file) and so you want to consider how any decision you make here
may lead to _increased_ resource usage by redownloading data you
removed.

These are just things to think about. It's an interesting space to
help users save disk.

Thanks,
-Stolee



  reply	other threads:[~2026-02-25 11:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25  6:17 [GSOC] Discuss and Introduction: Improve disk space recovery for partial clones Amisha Chhajed
2026-02-25 11:49 ` Derrick Stolee [this message]
2026-03-01 15:34   ` Amisha Chhajed

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=735eb76e-44a9-4f79-b769-23a3a07437ae@gmail.com \
    --to=stolee@gmail.com \
    --cc=amishhhaaaa@gmail.com \
    --cc=ayu.chandekar@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jltobler@gmail.com \
    --cc=karthik.188@gmail.com \
    --cc=siddharthasthana31@gmail.com \
    /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