# [GSoC] question for an additional objective 4 messages from 2026-03-11 to 2026-03-16. Participants: Pablo, Chandra Pratap, Karthik Nayak. Thread: https://gitlist.dev/t/65211 ## Pablo, 2026-03-11 17:13 Subject: [GSoC] question for an additional objective Message-ID: URL: https://gitlist.dev/e/CAN5EUNSxS_A%3DXT7cmUiQ9bsS5vtzB_KAb8URCzc3X5AzkQci8w%40mail.gmail.com ``` Hi! I'm working on my proposal for 'Complete and extend the remote-object-info command for git cat-file' While thinking about what else I could suggest to contribute to the project, I had an idea I would like to get feedback on: In a partial clone, someone might want to know what blobs are missing inside a concrete tree and their size before fetching them. The idea is to build on top of 'remote-object-info': given a tree hash, return the missing blobs (inside that tree) ordered by size. Is this too ambitious to be on the same project or even a good idea? Thanks, Pablo. ``` ## Chandra Pratap, 2026-03-14 06:11 Subject: Re: [GSoC] question for an additional objective Message-ID: URL: https://gitlist.dev/e/CA%2BJ6zkQMN0MnR7OG0vr6B0fa7jefOSP7B2qG%3Dfhv_zYubg5gWA%40mail.gmail.com In-Reply-To: ``` On Wed, 11 Mar 2026 at 22:43, Pablo wrote: > > Hi! > I'm working on my proposal for > 'Complete and extend the remote-object-info command for git cat-file' > > While thinking about what else I could suggest to contribute to the project, > I had an idea I would like to get feedback on: > In a partial clone, someone might want to know what blobs are missing inside > a concrete tree and their size before fetching them. > > The idea is to build on top of 'remote-object-info': given a tree hash, > return the missing blobs (inside that tree) ordered by size. > > Is this too ambitious to be on the same project or even a good idea? I haven't caught up on the remote-object-info work yet so I cannot tell you if this is too ambitious or not, but as far as your proposal is concerned, you can add these ideas to a 'Future Work' section and maybe try exploring it further during pre-GSoC and Community Bonding periods. The best way to discuss changes like this is through [RFC] threads where you submit an initial draft of what your proposed change is going to look like. It is always easier to understand what you're trying to do when there's code to look at. Motivates the reviewers as well when they see that you've put some effort in your idea ;) An example here: https://lore.kernel.org/git/xmqq5x72m4lu.fsf@gitster.g/ Thanks, Chandra. ``` ## Pablo, 2026-03-14 18:47 Subject: Re: [GSoC] question for an additional objective Message-ID: URL: https://gitlist.dev/e/CAN5EUNTO8jez1Rc3t-27u29yUYr6wt265shG%3DQUiKC-65qDwGA%40mail.gmail.com In-Reply-To: ``` Hi Chandra, Thanks, I didn't know about the [RFC], I'll note that. This would have to work on top of Eric and Calvin's work that has to be rebased and fixed, once that is done I'm up to drafting some code about how it would have to be. Thanks, Pablo ``` ## Karthik Nayak, 2026-03-16 23:07 Subject: Re: [GSoC] question for an additional objective Message-ID: URL: https://gitlist.dev/e/CAOLa%3DZSJt%2B6Gr%3D%3DY6Y_vnya4x6B%2B4Zt6cuT98NdEtpspdAgLkQ%40mail.gmail.com In-Reply-To: ``` Pablo writes: > Hi Chandra, > Thanks, I didn't know about the [RFC], I'll note that. This would have > to work on top of Eric and Calvin's work that has to be rebased and > fixed, once that is done I'm up to drafting some code about how it > would have to be. > > Thanks, > Pablo I agree with Chandra, I think it is a good idea, but better to be conservative with the timeline. Mostly since reviews often take longer than expected. Another tip is to not top post! ```