From: Christian Couder Date: Mon, 16 Mar 2026 12:08:36 GMT Subject: Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file Message-ID: In-Reply-To: <20260305204809.54927-1-valusoutrik@gmail.com> Hi, Sorry for the late feedback. On Thu, Mar 5, 2026 at 9:48 PM SoutrikDas wrote: > I have read through most of Eric Ju's [4] work and some of Calvin Wan's [5] > work. I am still finding more things to understand from each thread, but > I feel I have grasped the basics. > > My work in this project would be focused on implementing the changes > suggested at the end of Eric Ju's [Patch v11]. > > I wouldn't say I understand every bit of discussion from that thread, > but in general my understanding is : > > Calvin Wan and Eric Ju has already implemented a client side command s/has/have/ > called get_remote_info but its designed for being batched to reduce s/its/it's/ > multiple network trips to get a single object's data. The `git cat-file` command has a `--batch-command[=]` option to enter a command mode. In this command mode some special commands and arguments can be passed via stdin to `git cat-file` to request information. [...] > ## Project : Complete and extend the remote-object-info command for git cat-file > > Currently in the case of a partial clone, the user cannot retrieve all > object data without fetching the object beforehand. To solve this problem > Calvin Wan and Eric Ju had designed a patch sreies that can solve that, s/sreies/series/ > by utilising protocolv2 servers capabilities. > > This was done in the form of "remote-object-info". > > But only the %(objectsize) was implemented, and that patch was not merged. > This project has two goals > > 1: To Rebase and finalize Calvin Wan and Eric Ju's Work by addressing > the feedback on Eric Ju's Patch v11 > > 2: To add support for objecttype in remote-object-info > > 3: To discuss other information type like objectsize:disk and deltabase. s/type/types/ But anyway I think "information type" is not a good wording for these things, because we already talk about "type" for Git object types. Please try to find a better wording. > ## Timeline > > Mar 6-31 : Refine Proposal > > If possible I would like to submit small patches... but first I will > have to rebase Eric Ju's Patches ... I am not sure if I can do this > before GSOC... You can try a rebase to see which issues would need to be resolved to complete a rebase, and talk a bit about these issues in your proposal, but otherwise applicants shouldn't start working on a project before they have been accepted. > If not, I plan to contribute to git in other areas. > > May 1-24 : Community Bonding > 1-7 : Understand relevant underlying/ helper functions > 8-24 : Ask about any design related problems/decisions > > May 25 - Jun 14 : Start a Patch Series to rebase Calvin Wan and Eric Ju's work > and keep refining > > Jun 15 - Aug 15 : Start and keep refining Patch Series to add support for > object type information Would you implement both the client and the server side in the same patch series or do it separately? > Aug 16 - Aug 24 : Discuss and Implement other object information if possible > Concurrently I shall make a report for all the work done. > > ## Availability > > My current semester is ending in the first week of April, so I will be > able to contribute 7-8 hours per day, totalling around 35-40 hrs a week > on the project. Do you have another semester starting after the current one? > Total weeks = 12 , total hours = 35*12 = 420 > It leaves with a lot more room to accomodate any unforeseen circumstances > that may arise during the project. > > ## RFC > > I have a few ideas but do not know if they are worth pursuing, so I will > leave them here in the first draft > > - Addition of a remote-object-info outside of batchmode : > Yes it should be optimally used in batch mode .. but if user wants > only one objects size or type then should they be able to just > `git cat-file -r origin ` > and get the size and type ? or something similar , I am not sure if > the way I have depicted it conforms to git's design. Not sure if that would be very useful first. Also that might be better in a different command than `cat-file`. > - Addition of commands for common user behaviour : > I dont know if its going to be a common user behaviour but what about > `git cat-file -r --all-absent` > Or inside "git cat-file --batch-command=" remote-object-info > --all-absent --type=tree " > which would basically fill in remote-object-info with all the blobs > that are currently absent from the worktree ? There are other ways to do this, like using: git rev-list --objects --all --missing=print Thanks for your proposal. Best.