{"thread":{"id":"65174","subject":"[QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","startedAt":"2026-03-09T12:14:05Z","lastAt":"2026-03-24T11:05:02Z","messageCount":7,"participants":["Yuvraj Singh Chauhan","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"538261","messageId":"aa65h6Z_TrpJbmkj@ThinkPad-E14-Gen-6","threadId":"65174","inReplyTo":null,"subject":"[QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","fromName":"Yuvraj Singh Chauhan","fromEmail":"ysinghcin@gmail.com","sentAt":"2026-03-09T12:13:59Z","receivedAt":"2026-03-09T12:14:05Z","isPatch":false,"sender":{"key":"ysinghcin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/133221941?v=4"},"body":"Hi,\n\nI'm interested in working on the \"Improve disk space recovery for partial clones\" project.\nI am studying the codebase, particularly promisor-remote.c, builtin/backfill.c,\nand the partial clone documentation.\n\nI have a question to clarify the scope and direction of the project.\nThe project description mentions that git-backfill vs git-gc vs \ngit-repack vs git-maintenance is still undecided.\nHas there been any recent discussion or consensus on this?\nI want to make sure my proposal aligns with the community's direction.\n\nsincerely,\n\nYuvraj\n"},{"id":"538276","messageId":"CAP8UFD3sicsPd903FU8bsj2B_4Q1DE1xB+--OxryY_jhL=sHdw@mail.gmail.com","threadId":"65174","inReplyTo":"aa65h6Z_TrpJbmkj@ThinkPad-E14-Gen-6","subject":"Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-09T13:46:06Z","receivedAt":"2026-03-09T13:46:20Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Yuvraj,\n\nOn Mon, Mar 9, 2026 at 1:14 PM Yuvraj Singh Chauhan <ysinghcin@gmail.com> wrote:\n>\n> Hi,\n>\n> I'm interested in working on the \"Improve disk space recovery for partial clones\" project.\n> I am studying the codebase, particularly promisor-remote.c, builtin/backfill.c,\n> and the partial clone documentation.\n\nThanks for your interest in Git and this project.\n\n> I have a question to clarify the scope and direction of the project.\n> The project description mentions that git-backfill vs git-gc vs\n> git-repack vs git-maintenance is still undecided.\n> Has there been any recent discussion or consensus on this?\n> I want to make sure my proposal aligns with the community's direction.\n\nI don't think that there is a consensus on this. It seems to me that\nsomeone said that git-backfill was likely not the best command for\nthis, but I don't remember where and when this happened. It could have\nbeen in a private discussion.\n\nBest.\n"},{"id":"538277","messageId":"aa7XkqhcG6Kb6IhN@ThinkPad-E14-Gen-6","threadId":"65174","inReplyTo":"CAP8UFD3sicsPd903FU8bsj2B_4Q1DE1xB+--OxryY_jhL=sHdw@mail.gmail.com","subject":"Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","fromName":"Yuvraj Singh Chauhan","fromEmail":"ysinghcin@gmail.com","sentAt":"2026-03-09T14:22:10Z","receivedAt":"2026-03-09T14:22:16Z","isPatch":false,"sender":{"key":"ysinghcin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/133221941?v=4"},"body":"On Mon, Mar 09, 2026 at 02:46:06PM +0100, Christian Couder wrote:\n> Hi Yuvraj,\n> \n> On Mon, Mar 9, 2026 at 1:14 PM Yuvraj Singh Chauhan <ysinghcin@gmail.com> wrote:\n> >\n> > Hi,\n> >\n> > I'm interested in working on the \"Improve disk space recovery for partial clones\" project.\n> > I am studying the codebase, particularly promisor-remote.c, builtin/backfill.c,\n> > and the partial clone documentation.\n> \n> Thanks for your interest in Git and this project.\n> \n> > I have a question to clarify the scope and direction of the project.\n> > The project description mentions that git-backfill vs git-gc vs\n> > git-repack vs git-maintenance is still undecided.\n> > Has there been any recent discussion or consensus on this?\n> > I want to make sure my proposal aligns with the community's direction.\n> \n> I don't think that there is a consensus on this. It seems to me that\n> someone said that git-backfill was likely not the best command for\n> this, but I don't remember where and when this happened. It could have\n> been in a private discussion.\n> \n> Best.\n\nSo should I understand the all the different ways and create a document for the command\nI think would be a good fit and why. And then the community can give their opinion on it?\n\nsincerely,\nYuvraj\n"},{"id":"538279","messageId":"CAP8UFD2iM-z7F_FeDkP5v=1OAJhS2AcFsgPnicvHNFMUcmxbpQ@mail.gmail.com","threadId":"65174","inReplyTo":"aa7XkqhcG6Kb6IhN@ThinkPad-E14-Gen-6","subject":"Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-09T14:47:13Z","receivedAt":"2026-03-09T14:47:28Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Mar 9, 2026 at 3:22 PM Yuvraj Singh Chauhan <ysinghcin@gmail.com> wrote:\n\n> So should I understand the all the different ways and create a document for the command\n> I think would be a good fit and why. And then the community can give their opinion on it?\n\nYes, I think that in your proposal you can start discussing how it\ncould be introduced into the different commands. You can describe the\npros and cons of the different possibilities. Then maybe some\ndiscussion will happen when we will review your proposal and perhaps\nthat will lead to a consensus.\n"},{"id":"538308","messageId":"aa8VWlv7dosrrRwv@ThinkPad-E14-Gen-6","threadId":"65174","inReplyTo":"CAP8UFD2iM-z7F_FeDkP5v=1OAJhS2AcFsgPnicvHNFMUcmxbpQ@mail.gmail.com","subject":"Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","fromName":"Yuvraj Singh Chauhan","fromEmail":"ysinghcin@gmail.com","sentAt":"2026-03-09T18:45:46Z","receivedAt":"2026-03-09T18:45:53Z","isPatch":false,"sender":{"key":"ysinghcin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/133221941?v=4"},"body":"I have been studying the different commands and how they work, I will put together\nmy understanding in a pros and cons list for each command and send it asap.\n\nAlso the contributor application period starts March 16 and ends on the March 31.\nCan I complete my proposal for community review in between that period as well? or\nshould I rush to write a draft version before that.\n\nsincerely,\nYuvraj\n"},{"id":"539719","messageId":"acD-esOCTH3PpK9y@ThinkPad-E14-Gen-6","threadId":"65174","inReplyTo":"aa8VWlv7dosrrRwv@ThinkPad-E14-Gen-6","subject":"Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","fromName":"Yuvraj Singh Chauhan","fromEmail":"ysinghcin@gmail.com","sentAt":"2026-03-23T08:48:58Z","receivedAt":"2026-03-23T08:49:07Z","isPatch":false,"sender":{"key":"ysinghcin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/133221941?v=4"},"body":"On Tue, Mar 10, 2026 at 12:15:46AM +0530, Yuvraj Singh Chauhan wrote:\n> I have been studying the different commands and how they work, I will put together\n> my understanding in a pros and cons list for each command and send it asap.\n> \n> Also the contributor application period starts March 16 and ends on the March 31.\n> Can I complete my proposal for community review in between that period as well? or\n> should I rush to write a draft version before that.\n> \n> sincerely,\n> Yuvraj\n\nAfter some studying here the four options for placement:\n\nOption A: git backfill --evict\nRemark: '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.\n\nOption B: git gc / git repack\nRemark: 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.\n\nOption C: git maintenance task\nRemark: 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.\n\nOption D: git evict (standalone command)\nRemark: 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.\n\nPlease review so that I can create the proposed plan accordingly\n\nsincerely,\nYuvraj Singh Chauhan\n"},{"id":"539829","messageId":"CAP8UFD1HsRX3kzs39qa3yfix4ORCR4vzy+ddvU+Gz9OyJ-BsfA@mail.gmail.com","threadId":"65174","inReplyTo":"acD-esOCTH3PpK9y@ThinkPad-E14-Gen-6","subject":"Re: [QUESTION] Improving disk space recovery for partial clones (GSoC 2026)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-24T11:04:50Z","receivedAt":"2026-03-24T11:05:02Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Mar 23, 2026 at 9:49 AM Yuvraj Singh Chauhan\n<ysinghcin@gmail.com> wrote:\n>\n> On Tue, Mar 10, 2026 at 12:15:46AM +0530, Yuvraj Singh Chauhan wrote:\n> > I have been studying the different commands and how they work, I will put together\n> > my understanding in a pros and cons list for each command and send it asap.\n> >\n> > Also the contributor application period starts March 16 and ends on the March 31.\n> > Can I complete my proposal for community review in between that period as well? or\n> > should I rush to write a draft version before that.\n\nWe prefer it when proposals are sent to the mailing list for review\nbetween one month and one week before the end of the application\nperiod, so that they are quite up-to-date with recent developments and\ndiscussions, but we hopefully still have time to review them at least\nonce.\n\nSo you should send one soon if you haven't already.\n\n> After some studying here the four options for placement:\n>\n> Option A: git backfill --evict\n> 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.\n\ns/wont/won't/\n\n> Option B: git gc / git repack\n> 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.\n>\n> Option C: git maintenance task\n> 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.\n>\n> Option D: git evict (standalone command)\n> 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.\n>\n> Please review so that I can create the proposed plan accordingly\n\nWe cannot anticipate right now without proper patches with commit\nmessages, documentation, tests, etc what the best solution is. So you\nshould likely add your analysis of these options to your proposal\nwithout expecting much from some of us taking a look at them now.\n\nThanks.\n"}]}