Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file
- From
Karthik Nayak <karthik.188@gmail.com>
- Date
- Mar 16, 2026, 20:46 UTC
- Message-ID
- <CAOLa=ZQhzvgA2bpmUgx2qMTrxFaR5_6GET8e1y+A=m2nboDAiw@mail.gmail.com>
- In-Reply-To
- <20260305204809.54927-1-valusoutrik@gmail.com>
SoutrikDas <valusoutrik@gmail.com> writes:
Hello,
[snip]
Show 29 quoted lines
> ## Pre GSOC > > I started exploring Git's codebase around February 2026 and sent my first patch > as a docfix, followed by a microproject of modernizing tests > > - [PATCH] doc: fix repo_config documentation reference [1] > status: merged to master > Merge Commit: 94336d77bcbf4360b67a9454d8bf2e84b3d88ae7 > Description: Replace the path for the repo_config() documentation > from 'Documentation/technical/api-config.h' to 'config.h'. > > - [GSOC PATCH] t7003: modernize path existence checks using test helpers [2] > status: merged to master > Merge Commit: 11294bb0fa540d214d071b32cf74b1ed37b3bbbd > Description: Replace direct uses of 'test -f' and 'test -d' with > git's helper functions 'test_path_is_file' ,'test_path_is_missing' > and 'test_path_is_dir' > > > 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 : >
I do agree that there is a lot to unpack there.
> Calvin Wan and Eric Ju has already implemented a client side command > called get_remote_info but its designed for being batched to reduce > multiple network trips to get a single object's data. >
As far as I can recall, the command allowed users to enter multiple OIDs in a single line to reduce the to-fro with the server. But you could still fetch single OID info.
Show 7 quoted lines
> I have added Eric Ju's patch series to an old master commit (2d2a71ce85) > since I could not find a base commit for Eric's patch series. The patch > was properly applied and I also played around and added a very rough > but workin "%(objecttype)" code , ie now it prints like this : > > 29658341f39210201ff7f72a4be83937cf2288c5 14 blob >
Nice, have you tried with a more recent 'master'? I assume there are merge conflicts?
Show 16 quoted lines
> > ## 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, > 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 >
Any idea how much work is left post v11?
Show 14 quoted lines
> 2: To add support for objecttype in remote-object-info > > 3: To discuss other information type like objectsize:disk and deltabase. > > Project Duration : 12 week approx > > ## 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... >
As per the guidelines, it says
Any work done on the Project prior to acceptance of the Project Proposal will not be considered for Evaluations.
Show 14 quoted lines
> 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 > > Aug 16 - Aug 24 : Discuss and Implement other object information if possible > Concurrently I shall make a report for all the work done.
How will you manage reviews, considering generally they take a long time?
Show 23 quoted lines
> > ## 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. > > 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 <oid>` > 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. >
I do agree that something like that would be useful indeed, I'm not sure of what that design looks like though.
Show 8 quoted lines
> - 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="<format> remote-object-info > --all-absent --type=tree <remote>" > which would basically fill in remote-object-info with all the blobs > that are currently absent from the worktree ? > No need to fill them if its for a common enough use case.
I do see benefits of this too. But I do wonder if 'git rev-list' is a better command for something like this.
> - Sort according to size : > Maybe a user would want to check whats the largest file they dont > have yet. >
Same here.
> - Get total missing blob size : > Use case would be when someone wants to know how much exactly there > is to download, before starting the download. >
This could probably go into 'git backfill' ? Interesting ideas nevertheless!
Show 6 quoted lines
> Thank you for your time in revewing my proposal as well as considering > my application. I am excited to learn everything I can from git. > > Thanks and Regards, > Soutrik >
What I missed from the proposal: 1. Where did the work from Eric and Calvin stop at, what review comments need to be addressed. 2. How do you plan to handle reviews and iterations taking time.
Regards, Karthik
Show 6 quoted lines
> > [1] : pull.2187.git.git.1770293021383.gitgitgadget@gmail.com > [2] : 20260209172445.39536-1-valusoutrik@gmail.com > [3] : 20260225190306.39358-1-valusoutrik@gmail.com > [4] : 20240628190503.67389-1-eric.peijian@gmail.com > [5] : 20220728230210.2952731-1-calvinwan@google.com