{"thread":{"id":"65143","subject":"[GSOC Proposal] Complete and extend the remote-object-info command for git cat-file","startedAt":"2026-03-05T20:48:30Z","lastAt":"2026-03-20T13:12:28Z","messageCount":7,"participants":["SoutrikDas","Christian Couder","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"537997","messageId":"20260305204809.54927-1-valusoutrik@gmail.com","threadId":"65143","inReplyTo":null,"subject":"[GSOC Proposal] Complete and extend the remote-object-info command for git cat-file","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-03-05T20:48:09Z","receivedAt":"2026-03-05T20:48:30Z","isPatch":false,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"\nHi!\n\nThis is my project proposal for GSOC 2026\n\nI am interested in the project idea : \"Complete and extend the \nremote-object-info command for git cat-file\"\n\n\n# Complete and extend the remote-object-info command for git cat-file\n\n## Contact\n\n- Name: Soutrik Das\n- E-mail: valusoutrik@gmail.com\n- Github: https://github.com/SoutrikDas\n- LinkedIn: https://www.linkedin.com/in/soutrik-das/\n\n## About Me\n\nMy name is Soutrik Das, I am a developer and CS bachelor from Indian \nInstitute of Technology, Dhanbad. Currently I am pursuing a master's\ndegree in AI from Indian Institute of Technology, Bhubaneswar.\n\nI dont really have much experience in contributing to something as \nlarge as git, but I would love to learn anything and everything I can\ngain from this experience. I have experience in C/C++ from my\nBtech coursework and participating in codeforces contests.\n\n\n## Pre GSOC\n\nI started exploring Git's codebase around February 2026 and sent my first patch\nas a docfix, followed by a microproject of modernizing tests \n\n- [PATCH] doc: fix repo_config documentation reference [1]\n status: merged to master \n Merge Commit: 94336d77bcbf4360b67a9454d8bf2e84b3d88ae7\n Description: Replace the path for the repo_config() documentation \n from 'Documentation/technical/api-config.h' to 'config.h'.\n\n- [GSOC PATCH] t7003: modernize path existence checks using test helpers [2]\n status: merged to master \n Merge Commit: 11294bb0fa540d214d071b32cf74b1ed37b3bbbd\n Description: Replace direct uses of 'test -f' and 'test -d' with\n git's helper functions 'test_path_is_file' ,'test_path_is_missing'\n and 'test_path_is_dir'\n\n\nI have read through most of Eric Ju's [4] work and some of Calvin Wan's [5]\nwork. I am still finding more things to understand from each thread, but \nI feel I have grasped the basics.\n\nMy work in this project would be focused on implementing the changes\nsuggested at the end of Eric Ju's [Patch v11].\n\nI wouldn't say I understand every bit of discussion from that thread,\nbut in general my understanding is :\n\nCalvin Wan and Eric Ju has already implemented a client side command\ncalled get_remote_info but its designed for being batched to reduce\nmultiple network trips to get a single object's data. \n\nI have added Eric Ju's patch series to an old master commit (2d2a71ce85)\nsince I could not find a base commit for Eric's patch series. The patch\nwas properly applied and I also played around and added a very rough\nbut workin \"%(objecttype)\" code , ie now it prints like this : \n\n29658341f39210201ff7f72a4be83937cf2288c5 14 blob\n\n\n## Project : Complete and extend the remote-object-info command for git cat-file\n\nCurrently in the case of a partial clone, the user cannot retrieve all \nobject data without fetching the object beforehand. To solve this problem\nCalvin Wan and Eric Ju had designed a patch sreies that can solve that,\nby utilising protocolv2 servers capabilities.\n\nThis was done in the form of \"remote-object-info\".\n\nBut only the %(objectsize) was implemented, and that patch was not merged. \nThis project has two goals \n\n1: To Rebase and finalize Calvin Wan and Eric Ju's Work by addressing\n the feedback on Eric Ju's Patch v11 \n\n2: To add support for objecttype in remote-object-info\n\n3: To discuss other information type like objectsize:disk and deltabase.\n\nProject Duration : 12 week approx\n\n## Timeline \n\nMar 6-31 : Refine Proposal\n\n If possible I would like to submit small patches... but first I will\n have to rebase Eric Ju's Patches ... I am not sure if I can do this\n before GSOC...\n\n If not, I plan to contribute to git in other areas.\n\nMay 1-24 : Community Bonding \n 1-7 : Understand relevant underlying/ helper functions\n 8-24 : Ask about any design related problems/decisions\n\nMay 25 - Jun 14 : Start a Patch Series to rebase Calvin Wan and Eric Ju's work\n and keep refining\n\nJun 15 - Aug 15 : Start and keep refining Patch Series to add support for\n object type information\n\nAug 16 - Aug 24 : Discuss and Implement other object information if possible\n Concurrently I shall make a report for all the work done.\n\n## Availability\n\nMy current semester is ending in the first week of April, so I will be\nable to contribute 7-8 hours per day, totalling around 35-40 hrs a week\non the project.\n\nTotal weeks = 12 , total hours = 35*12 = 420 \nIt leaves with a lot more room to accomodate any unforeseen circumstances\nthat may arise during the project.\n\n## RFC \n\nI have a few ideas but do not know if they are worth pursuing, so I will\nleave them here in the first draft \n\n- Addition of a remote-object-info outside of batchmode :\n Yes it should be optimally used in batch mode .. but if user wants\n only one objects size or type then should they be able to just \n `git cat-file -r origin ` \n and get the size and type ? or something similar , I am not sure if\n the way I have depicted it conforms to git's design.\n\n- Addition of commands for common user behaviour :\n I dont know if its going to be a common user behaviour but what about\n `git cat-file -r --all-absent` \n Or inside \"git cat-file --batch-command=\" remote-object-info \n --all-absent --type=tree \"\n which would basically fill in remote-object-info with all the blobs\n that are currently absent from the worktree ?\n No need to fill them if its for a common enough use case.\n\n- Sort according to size :\n Maybe a user would want to check whats the largest file they dont\n have yet.\n\n- Get total missing blob size :\n Use case would be when someone wants to know how much exactly there\n is to download, before starting the download.\n \nThank you for your time in revewing my proposal as well as considering\nmy application. I am excited to learn everything I can from git.\n\nThanks and Regards,\nSoutrik\n\n\n[1] : pull.2187.git.git.1770293021383.gitgitgadget@gmail.com\n[2] : 20260209172445.39536-1-valusoutrik@gmail.com\n[3] : 20260225190306.39358-1-valusoutrik@gmail.com\n[4] : 20240628190503.67389-1-eric.peijian@gmail.com\n[5] : 20220728230210.2952731-1-calvinwan@google.com\n"},{"id":"539022","messageId":"20260315101154.80383-1-valusoutrik@gmail.com","threadId":"65143","inReplyTo":"20260305204809.54927-1-valusoutrik@gmail.com","subject":"Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-03-15T10:11:54Z","receivedAt":"2026-03-15T10:12:17Z","isPatch":false,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"Hi I was wondering If I could get some feedback on this.\n\nThanks.\n"},{"id":"539102","messageId":"CAP8UFD3LJEU1YNBOi5VtpZANTY9PA3_v=eU9JF163F2efp-hGg@mail.gmail.com","threadId":"65143","inReplyTo":"20260305204809.54927-1-valusoutrik@gmail.com","subject":"Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-16T12:08:36Z","receivedAt":"2026-03-16T12:08:49Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nSorry for the late feedback.\n\nOn Thu, Mar 5, 2026 at 9:48 PM SoutrikDas wrote:\n\n> I have read through most of Eric Ju's [4] work and some of Calvin Wan's [5]\n> work. I am still finding more things to understand from each thread, but\n> I feel I have grasped the basics.\n>\n> My work in this project would be focused on implementing the changes\n> suggested at the end of Eric Ju's [Patch v11].\n>\n> I wouldn't say I understand every bit of discussion from that thread,\n> but in general my understanding is :\n>\n> Calvin Wan and Eric Ju has already implemented a client side command\n\ns/has/have/\n\n> called get_remote_info but its designed for being batched to reduce\n\ns/its/it's/\n\n> multiple network trips to get a single object's data.\n\nThe `git cat-file` command has a `--batch-command[=]` option\nto enter a command mode. In this command mode some special commands\nand arguments can be passed via stdin to `git cat-file` to request\ninformation.\n\n[...]\n\n> ## Project : Complete and extend the remote-object-info command for git cat-file\n>\n> Currently in the case of a partial clone, the user cannot retrieve all\n> object data without fetching the object beforehand. To solve this problem\n> Calvin Wan and Eric Ju had designed a patch sreies that can solve that,\n\ns/sreies/series/\n\n> by utilising protocolv2 servers capabilities.\n>\n> This was done in the form of \"remote-object-info\".\n>\n> But only the %(objectsize) was implemented, and that patch was not merged.\n> This project has two goals\n>\n> 1: To Rebase and finalize Calvin Wan and Eric Ju's Work by addressing\n> the feedback on Eric Ju's Patch v11\n>\n> 2: To add support for objecttype in remote-object-info\n>\n> 3: To discuss other information type like objectsize:disk and deltabase.\n\ns/type/types/\n\nBut anyway I think \"information type\" is not a good wording for these\nthings, because we already talk about \"type\" for Git object types.\nPlease try to find a better wording.\n\n> ## Timeline\n>\n> Mar 6-31 : Refine Proposal\n>\n> If possible I would like to submit small patches... but first I will\n> have to rebase Eric Ju's Patches ... I am not sure if I can do this\n> before GSOC...\n\nYou can try a rebase to see which issues would need to be resolved to\ncomplete a rebase, and talk a bit about these issues in your proposal,\nbut otherwise applicants shouldn't start working on a project before\nthey have been accepted.\n\n> If not, I plan to contribute to git in other areas.\n>\n> May 1-24 : Community Bonding\n> 1-7 : Understand relevant underlying/ helper functions\n> 8-24 : Ask about any design related problems/decisions\n>\n> May 25 - Jun 14 : Start a Patch Series to rebase Calvin Wan and Eric Ju's work\n> and keep refining\n>\n> Jun 15 - Aug 15 : Start and keep refining Patch Series to add support for\n> object type information\n\nWould you implement both the client and the server side in the same\npatch series or do it separately?\n\n> Aug 16 - Aug 24 : Discuss and Implement other object information if possible\n> Concurrently I shall make a report for all the work done.\n>\n> ## Availability\n>\n> My current semester is ending in the first week of April, so I will be\n> able to contribute 7-8 hours per day, totalling around 35-40 hrs a week\n> on the project.\n\nDo you have another semester starting after the current one?\n\n> Total weeks = 12 , total hours = 35*12 = 420\n> It leaves with a lot more room to accomodate any unforeseen circumstances\n> that may arise during the project.\n>\n> ## RFC\n>\n> I have a few ideas but do not know if they are worth pursuing, so I will\n> leave them here in the first draft\n>\n> - Addition of a remote-object-info outside of batchmode :\n> Yes it should be optimally used in batch mode .. but if user wants\n> only one objects size or type then should they be able to just\n> `git cat-file -r origin `\n> and get the size and type ? or something similar , I am not sure if\n> the way I have depicted it conforms to git's design.\n\nNot sure if that would be very useful first. Also that might be better\nin a different command than `cat-file`.\n\n> - Addition of commands for common user behaviour :\n> I dont know if its going to be a common user behaviour but what about\n> `git cat-file -r --all-absent`\n> Or inside \"git cat-file --batch-command=\" remote-object-info\n> --all-absent --type=tree \"\n> which would basically fill in remote-object-info with all the blobs\n> that are currently absent from the worktree ?\n\nThere are other ways to do this, like using:\n\ngit rev-list --objects --all --missing=print\n\nThanks for your proposal.\n\nBest.\n"},{"id":"539159","messageId":"CAOLa=ZQhzvgA2bpmUgx2qMTrxFaR5_6GET8e1y+A=m2nboDAiw@mail.gmail.com","threadId":"65143","inReplyTo":"20260305204809.54927-1-valusoutrik@gmail.com","subject":"Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-03-16T20:46:29Z","receivedAt":"2026-03-16T20:46:31Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"SoutrikDas writes:\n\nHello,\n\n[snip]\n\n> ## Pre GSOC\n>\n> I started exploring Git's codebase around February 2026 and sent my first patch\n> as a docfix, followed by a microproject of modernizing tests\n>\n> - [PATCH] doc: fix repo_config documentation reference [1]\n> status: merged to master\n> Merge Commit: 94336d77bcbf4360b67a9454d8bf2e84b3d88ae7\n> Description: Replace the path for the repo_config() documentation\n> from 'Documentation/technical/api-config.h' to 'config.h'.\n>\n> - [GSOC PATCH] t7003: modernize path existence checks using test helpers [2]\n> status: merged to master\n> Merge Commit: 11294bb0fa540d214d071b32cf74b1ed37b3bbbd\n> Description: Replace direct uses of 'test -f' and 'test -d' with\n> git's helper functions 'test_path_is_file' ,'test_path_is_missing'\n> and 'test_path_is_dir'\n>\n>\n> I have read through most of Eric Ju's [4] work and some of Calvin Wan's [5]\n> work. I am still finding more things to understand from each thread, but\n> I feel I have grasped the basics.\n>\n> My work in this project would be focused on implementing the changes\n> suggested at the end of Eric Ju's [Patch v11].\n>\n> I wouldn't say I understand every bit of discussion from that thread,\n> but in general my understanding is :\n>\n\nI do agree that there is a lot to unpack there.\n\n> Calvin Wan and Eric Ju has already implemented a client side command\n> called get_remote_info but its designed for being batched to reduce\n> multiple network trips to get a single object's data.\n>\n\nAs far as I can recall, the command allowed users to enter multiple OIDs\nin a single line to reduce the to-fro with the server. But you could\nstill fetch single OID info.\n\n> I have added Eric Ju's patch series to an old master commit (2d2a71ce85)\n> since I could not find a base commit for Eric's patch series. The patch\n> was properly applied and I also played around and added a very rough\n> but workin \"%(objecttype)\" code , ie now it prints like this :\n>\n> 29658341f39210201ff7f72a4be83937cf2288c5 14 blob\n>\n\nNice, have you tried with a more recent 'master'? I assume there are\nmerge conflicts?\n\n>\n> ## Project : Complete and extend the remote-object-info command for git cat-file\n>\n> Currently in the case of a partial clone, the user cannot retrieve all\n> object data without fetching the object beforehand. To solve this problem\n> Calvin Wan and Eric Ju had designed a patch sreies that can solve that,\n> by utilising protocolv2 servers capabilities.\n>\n> This was done in the form of \"remote-object-info\".\n>\n> But only the %(objectsize) was implemented, and that patch was not merged.\n> This project has two goals\n>\n> 1: To Rebase and finalize Calvin Wan and Eric Ju's Work by addressing\n> the feedback on Eric Ju's Patch v11\n>\n\nAny idea how much work is left post v11?\n\n> 2: To add support for objecttype in remote-object-info\n>\n> 3: To discuss other information type like objectsize:disk and deltabase.\n>\n> Project Duration : 12 week approx\n>\n> ## Timeline\n>\n> Mar 6-31 : Refine Proposal\n>\n> If possible I would like to submit small patches... but first I will\n> have to rebase Eric Ju's Patches ... I am not sure if I can do this\n> before GSOC...\n>\n\nAs per the guidelines, it says\n\n Any work done on the Project prior to acceptance of the Project\n Proposal will not be considered for Evaluations.\n\n> If not, I plan to contribute to git in other areas.\n>\n> May 1-24 : Community Bonding\n> 1-7 : Understand relevant underlying/ helper functions\n> 8-24 : Ask about any design related problems/decisions\n>\n> May 25 - Jun 14 : Start a Patch Series to rebase Calvin Wan and Eric Ju's work\n> and keep refining\n>\n> Jun 15 - Aug 15 : Start and keep refining Patch Series to add support for\n> object type information\n>\n> Aug 16 - Aug 24 : Discuss and Implement other object information if possible\n> Concurrently I shall make a report for all the work done.\n\nHow will you manage reviews, considering generally they take a long\ntime?\n\n>\n> ## Availability\n>\n> My current semester is ending in the first week of April, so I will be\n> able to contribute 7-8 hours per day, totalling around 35-40 hrs a week\n> on the project.\n>\n> Total weeks = 12 , total hours = 35*12 = 420\n> It leaves with a lot more room to accomodate any unforeseen circumstances\n> that may arise during the project.\n>\n> ## RFC\n>\n> I have a few ideas but do not know if they are worth pursuing, so I will\n> leave them here in the first draft\n>\n> - Addition of a remote-object-info outside of batchmode :\n> Yes it should be optimally used in batch mode .. but if user wants\n> only one objects size or type then should they be able to just\n> `git cat-file -r origin `\n> and get the size and type ? or something similar , I am not sure if\n> the way I have depicted it conforms to git's design.\n>\n\nI do agree that something like that would be useful indeed, I'm not sure\nof what that design looks like though.\n\n> - Addition of commands for common user behaviour :\n> I dont know if its going to be a common user behaviour but what about\n> `git cat-file -r --all-absent`\n> Or inside \"git cat-file --batch-command=\" remote-object-info\n> --all-absent --type=tree \"\n> which would basically fill in remote-object-info with all the blobs\n> that are currently absent from the worktree ?\n> No need to fill them if its for a common enough use case.\n\nI do see benefits of this too. But I do wonder if 'git rev-list' is a\nbetter command for something like this.\n\n> - Sort according to size :\n> Maybe a user would want to check whats the largest file they dont\n> have yet.\n>\n\nSame here.\n\n> - Get total missing blob size :\n> Use case would be when someone wants to know how much exactly there\n> is to download, before starting the download.\n>\n\nThis could probably go into 'git backfill' ? Interesting ideas\nnevertheless!\n\n> Thank you for your time in revewing my proposal as well as considering\n> my application. I am excited to learn everything I can from git.\n>\n> Thanks and Regards,\n> Soutrik\n>\n\nWhat I missed from the proposal:\n1. Where did the work from Eric and Calvin stop at, what review comments\nneed to be addressed.\n2. How do you plan to handle reviews and iterations taking time.\n\nRegards,\nKarthik\n\n>\n> [1] : pull.2187.git.git.1770293021383.gitgitgadget@gmail.com\n> [2] : 20260209172445.39536-1-valusoutrik@gmail.com\n> [3] : 20260225190306.39358-1-valusoutrik@gmail.com\n> [4] : 20240628190503.67389-1-eric.peijian@gmail.com\n> [5] : 20220728230210.2952731-1-calvinwan@google.com\n"},{"id":"539218","messageId":"20260317130603.84482-1-valusoutrik@gmail.com","threadId":"65143","inReplyTo":"CAP8UFD3LJEU1YNBOi5VtpZANTY9PA3_v=eU9JF163F2efp-hGg@mail.gmail.com","subject":"Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-03-17T13:06:03Z","receivedAt":"2026-03-17T13:06:54Z","isPatch":false,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"Hi there,\n\n> s/has/have/\n> s/its/it's/\n> s/sreies/series/\n> s/type/types/\n\nI will correct all the spelling mistakes.\n\n> > multiple network trips to get a single object's data.\n> \n> The `git cat-file` command has a `--batch-command[=]` option\n> to enter a command mode. In this command mode some special commands\n> and arguments can be passed via stdin to `git cat-file` to request\n> information.\n\nWill correct that.\n\n> But anyway I think \"information type\" is not a good wording for these\n> things, because we already talk about \"type\" for Git object types.\n> Please try to find a better wording.\n\nHow about object property or object attribute or object field?\nI feel like object fields may be a bit more technically correct.\n\n> You can try a rebase to see which issues would need to be resolved to\n> complete a rebase, and talk a bit about these issues in your proposal,\n> but otherwise applicants shouldn't start working on a project before\n> they have been accepted.\n\nI tried a rebase on the current master , and there were indeed conflicts\nI will include this part in my v2.\n\n\n> Would you implement both the client and the server side in the same\n> patch series or do it separately?\n\nI am not sure actually... since Eric Ju did everything in one patch series.\nBut personally I feel like doing one series for server side first and another\nfor client side would be a bit more focused. But I am not sure if it would\ncost more time for everyone involved, like giving feedback and all that?\n\n> > My current semester is ending in the first week of April, so I will be\n> > able to contribute 7-8 hours per day, totalling around 35-40 hrs a week\n> > on the project.\n> \n> Do you have another semester starting after the current one?\n\nActually I made a mistake, its ending in the first week of May. But no, \nafter this semester we have a summer break so ... I will update this part.\n\n> Not sure if that would be very useful first. Also that might be better\n> in a different command than `cat-file`.\n\nAlright. I will ask that as a question before my final gsoc proposal\nsubmission so that if its approved, I will add it to my tasks in gsoc.\n\n> There are other ways to do this, like using:\n> \n> git rev-list --objects --all --missing=print\n\nDid not know that ... but thats great! I will remove this from the proposal.\n\nThanks for the feedback.\n"},{"id":"539225","messageId":"20260317151340.85141-1-valusoutrik@gmail.com","threadId":"65143","inReplyTo":"CAOLa=ZQhzvgA2bpmUgx2qMTrxFaR5_6GET8e1y+A=m2nboDAiw@mail.gmail.com","subject":"Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-03-17T15:13:40Z","receivedAt":"2026-03-17T15:14:09Z","isPatch":false,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"Hi there,\n\n> As far as I can recall, the command allowed users to enter multiple OIDs\n> in a single line to reduce the to-fro with the server. But you could\n> still fetch single OID info.\n\nYeah that was what I meant, but from Chistian Couder's feedback, I realized\nthat cat-file is not a good home for such a subcommand. \n\n> Nice, have you tried with a more recent 'master'? I assume there are\n> merge conflicts?\n\nYup, I will add these issues in my proposal v2.\n\n> Any idea how much work is left post v11?\n\nFrom the v11 thread \n- a lot of design decision fix , like comment alignment and blank lines\n- the max remote obj info logic is a bit wrong as Junio pointed out [1]\n- one test case for max obj limit\n- use of size_t for looping\n- the placeholder check ie the even with only objectsize the checking of\nformatting string is a bit incorrect [2]\n- Implementing an allow list for placeholders\n- print empty string for unsupported placeholders, ie those not on the\nallow list\n- remove usage of split_cmdline since neither url nor oid will have spaces\nin them, so a strchr would suffice, I think ?\n\nAbove is for just for part 1 ie to get eric jus patch accepted\n\n> As per the guidelines, it says\n> \n> Any work done on the Project prior to acceptance of the Project\n> Proposal will not be considered for Evaluations.\n\nI meant like in the May 1-24 duration, which is after the acceptance\nof the project ( april 30 ) but before coding officially begins (may 25)\n\nThis is the timeline on gsocs page [3]:\n> April 30 - 18:00 UTC\n> Accepted GSoC contributor projects announced\n> May 1 - 24\n> Community Bonding Period | GSoC contributors get to know mentors, \n> read documentation, get up to speed to begin working on their projects\n> May 25\n> Coding officially begins!\n\nI was planning to also ask design questions in this period.\n\n> How will you manage reviews, considering generally they take a long\n> time?\n\nI will adjust the timeline to give more time to rebase previously done work.\nI was wondering... I cannot start on part 2 ie adding support for more object\nfields without first integrating old work ... so about 50% of time will go to\nrebasing and 30% to adding new fields ? and 20% for emergency or any mishap.\n\n> I do agree that something like that would be useful indeed, I'm not sure\n> of what that design looks like though.\n> I do see benefits of this too. But I do wonder if 'git rev-list' is a\n> better command for something like this.\n\nI will clarify questions at the beginning of gsoc duration.\n\n\n> What I missed from the proposal:\n> 1. Where did the work from Eric and Calvin stop at, what review comments\n> need to be addressed.\n> 2. How do you plan to handle reviews and iterations taking time.\n\nWill update the timeline as well as mention the current outstanding tasks,\nas far as I have understood them.\n\nThank you for your feedback.\n\n\n[1] : xmqqo6yr3wc4.fsf@gitster.g/\n[2] : 20250224234720.GC729825@coredump.intra.peff.net/\n[3] : https://developers.google.com/open-source/gsoc/timeline\n"},{"id":"539546","messageId":"20260320131200.3615-1-valusoutrik@gmail.com","threadId":"65143","inReplyTo":"20260305204809.54927-1-valusoutrik@gmail.com","subject":"[GSoC Proposal v2] Complete and extend the remote-object-info command for git cat-file","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-03-20T13:12:00Z","receivedAt":"2026-03-20T13:12:28Z","isPatch":false,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"\nHi everyone,\nThank you for the feedback Christian and Karthik.\nI have not made a doc version of this yet. I will link it from v3\n\nI understand that in this proposal I have not explained my own plans that\nthoroughly, I am working on this in v3.\n\nChanges from v1 : \n- Correct spelling mistakes\n- Address how much work is remaining after Eric Ju's Patch v11\n- Increase Time in Timeline for Reviews\n- Add a section for rebasing problems\n\n---\n\nThis is the second version of my project proposal for GSoC 2026\n\nI am interested in the project idea : \"Complete and extend the \nremote-object-info command for git cat-file\"\n\n\n# Complete and extend the remote-object-info command for git cat-file\n\n## Contact\n\n- Name: Soutrik Das\n- E-mail: valusoutrik@gmail.com\n- Github: https://github.com/SoutrikDas\n- LinkedIn: https://www.linkedin.com/in/soutrik-das/\n\n## About Me\n\nMy name is Soutrik Das, I am a developer. I did my B.Tech in CS from \nIIT Dhanbad. Currently I am pursuing a M.Tech degree in AI from IIT \nBhubaneswar.\n\nI don't really have much experience in contributing to something as \nlarge as git, but I would like to learn as much as possible from this \nexperience. I have experience in C/C++ from my Btech coursework and \nparticipating in codeforces contests.\n\n\n## Pre GSoC\n\nI started exploring Git's codebase around February 2026 and sent my first patch\nas a docfix, followed by a microproject of modernizing tests \n\n- [PATCH] doc: fix repo_config documentation reference [1]\n status: merged to master \n Merge Commit: 94336d77bcbf4360b67a9454d8bf2e84b3d88ae7\n Merge Date : 13 Feb 2026\n Description: Replace the path for the repo_config() documentation \n from 'Documentation/technical/api-config.h' to 'config.h'.\n\n- [GSoC PATCH] t7003: modernize path existence checks using test helpers [2]\n status: merged to master \n Merge Commit: 11294bb0fa540d214d071b32cf74b1ed37b3bbbd\n Merge Date : 17 Feb 2026\n Description: Replace direct uses of 'test -f' and 'test -d' with\n git's helper functions 'test_path_is_file' ,'test_path_is_missing'\n and 'test_path_is_dir'\n\n\n## Eric Ju and Calvin Wan's work\n\nIn this section I want to talk about the work already done and what \nfeedback the community had on the last sent patch , ie v11 \n\nThis is my understanding of the patch series: \n\nPatch 1/8 : git-compat-util: add strtoul_ul()\n Helper function addition\n\nPatch 2/8 : cat-file: add declaration of variable i inside for loop\n Small refactoring\n\nPatch 3/8 : t1006: split test utility functions into new \"lib-cat-file.sh\"\n Moving the `echo_without_newline`,`echo_without_newline_nul` and \n `strlen` function from `t1006-cat-file.sh` to `lib-cat-file.sh` to\n reuse them in future. \n When I rebased the patch series against a recent master (March 5)\n 795c338de725e13bd361214c6b768019fc45a2c1, there is only one other\n file ( t1007-hash-object.sh ) that has a duplicate definition. \n\nPatch 4/8 : fetch-pack: refactor packet writing\n Generalized write_command_and_capabilities so that it now takes in\n a command instead of hardcoding \"fetch\". It was also moved from \n `fetch-pack.c` to `connect.c`\n\nPatch 5/8 : fetch-pack: move fetch initialization\n Before this patch, the state machine of do_fetch_pack_v2() used to\n assume that starting state is FETCH_CHECK_LOCAL so it would initialize\n certain variables like `use_sideband=2` inside the FETCH_CHECK_LOCAL\n case. But now for remote-object-info we do not want to go through\n the extra steps, we are directly entering the state machine at\n FETCH_SEND_REQUEST. We don't need to figure out what to fetch,\n the user/machine is explicitly giving it.\n\nPatch 6/8 : serve: advertise object-info feature\n Makes the server adertise that it supports the \"size\" feature of\n object-info command.\n\nPatch 7/8 : transport: add client support for object-info\n Adds `fetch_object_info` which checks if protocol is v2 \n and then sends the object info request. After getting the result\n its parsing the output. \n\n Also sets `state=FFETCH_SEND_REQUEST` when object-info is used.\n\nNot related to above patch , but on the server side this request is\ncaught by serve.c and then handled by cap_object_info in protocol-caps.c\n\nPatch 8/8 : cat-file: add remote-object-info to batch-command\n Adds the subcommands and relevant tests.\n\nTo summarize, this patch series has added the subcommand, and all of\nthe needed functions to make one object info field work. But a few problems\nwere left to be addressed. Once those are addressed, adding new object\ninfo fields will be much easier. \n\n## Problems faced during rebasing\n\nI applied the patches onto an old master (2d2a71ce85) and then rebased\nto a recent master (795c338de7) \n\nPatch 1/8: Auto / No Merge Conflict\n\nPatch 2/8: Auto / No Merge Conflict\n\nPatch 3/8: add/add conflict\n\nPatch 4/8: Confirming movement of function `write_command_and_capabilities`\n\nPatch 5/8: Auto / No Merge Conflict\n\nPatch 6/8: Auto / No Merge Conflict\n\nPatch 7/8: Makefile merge conflict but when opened in vscode it shows\n0 conflict.\n\nPatch 8/8: add/add conflict for object-store.c and modify/delete \nconflict for object-store-ll.h\nAccording to 68cd492a3e \n\n> object-store: merge \"object-store-ll.h\" and \"object-store.h\"\n\nAnd according to 8f49151763\n\n> object-store: rename files to \"odb.{c,h}\"\n\nTherefore I have added the function signature that was supposed to go to\nobject-store-ll.h to odb.h\n\n\n## Work remaining to get v11 patch accepted\n\nAlmost all of it is focused on patch 8 \n\n- Fix multi-line comment formatting - closing */ on own line\n- Add blank lines between macro definitions\n- Split overly-long MAX_REMOTE_OBJ_INFO_LINE definition across lines\n- Change loop variable from size_t i to int i (since argc is int)\n- Rearrange if/else to put smaller body first: if (!gtransport->smart_options)\n before else\n\n- Fix the logic of maximum line size for the remote-object-info.\n- Adding an allow list of object info fields \n- Handling what happens if an unsupported object info field is given in\n format string. \n In this case we send the request as if such a object info field is\n not even there, and when printing the result we simply print an empty\n string on the client side. No extra payload on the network. \n \n- Add tests.\n- Update Documentation \n \n\n\n## Project : Complete and extend the remote-object-info command for git cat-file\n\nCurrently in the case of a partial clone, the user cannot retrieve all \nobject data without fetching the object beforehand. To solve this problem\nCalvin Wan and Eric Ju had designed a patch series that can solve that,\nby utilising protocolv2 servers capabilities.\n\nThis was done in the form of \"remote-object-info\".\n\nBut only the %(objectsize) was implemented, and that patch was not merged. \nThis project has two goals \n\n1: To Rebase and finalize Calvin Wan and Eric Ju's Work by addressing\n the feedback on Eric Ju's Patch v11. Work for this part is discussed\n above in above section.\n\n2: To discuss with the community and add support for other relevant \n object info fields `remote-object-info` like `objecttype`, \n `objectsize:disk` and `deltabase`\n\nProject Duration : 13 week approx\n\n## Timeline \n\n\n### Phase 1 : \n\nMay 1-24 : Community Bonding + Start Design discussions on \n Logic of allow list implementation\n Logic of maximum size of the remote-object-info command\n Which object info fields should be supported\n\nWeek 1 (May 25 - 31) : \n Open Patch Series 1 for Eric Jus patch, after \n solving all remaining problems. Use the discussed idea/solution from \n above. Both client and server side work would be in the same patch \n series. This is just rebasing previous work so I have to address \n the changes suggested after v11.\n\nWeek 2 (June 1 - 7) : Continue discussion, review feedback and refine.\n\nWeek 3 (June 8 - 14) : Review feedback and refine\n\nWeek 4 (June 15 - 21) : Review feedback and refine + Update Documentation\n and Tests\n\nWeek 5 (June 22 - 28) : By now all tasks regarding Merging Eric Ju's \n patch should be finished. But since it may take more time for \n reviewing I am adding a buffer weeks.\n\nWeek 6 (June 29 - July 5) : Polish everything + Midterm report\n\nWeek 7 (July 6 - 12) : Midterm evaluation ( July 7-11)\n\nWeek 8 (July 13 - 19) : Start Patch Series 2 for adding other object info\n fields as per the discussion started in Week 1.\n\nWeek 9 (July 20 - 26) : Review feedback and refine.\n\nWeek 10 (July 27 - August 2) : Review feedback and refine. \n\nWeek 11 (August 3 - 9) : Finalize all tests and Doc changes.\n\nWeek 12 (August 10 - 16) : Prepare Final report.\n\nWeek 13 (August 17 - 23) : Final Evaluation ( Aug 18-24 )\n\n\n\n## Availability\n\nMy current semester is ending in the first week of May, so I will be\nable to contribute 7-8 hours per day, totalling around 35-40 hrs a week\non the project.\n\nTotal weeks = 13 , total hours = 35*13 = 455\nIt leaves with a lot more room to accommodate any unforeseen circumstances\nthat may arise during the project.\n\n## RFC \n\n\nHi Christian and Karthik !\n\nI still feel like the single object get remote info might be useful\nand I think this might be where I can add this functionality :\n\nWhen someone does `GIT_NO_LAZY_FETCH=0 git cat-file -s ` \nAnd the oid is of a blob that is not on local, then git simply fetches\nthe blob and reruns git cat-file -s. \n\nBut if someone does `GIT_NO_LAZY_FETCH=1 git cat-file -s ` \nAnd the blob is not on local then it exits with the following error\n\n>\tif (git_env_bool(NO_LAZY_FETCH_ENVIRONMENT, 0)) {\n>\t\tstatic int warning_shown;\n>\t\tif (!warning_shown) {\n>\t\t\twarning_shown = 1;\n>\t\t\twarning(_(\"lazy fetching disabled; some objects may not be available\"));\n>\t\t}\n>\t\treturn -1;\n>\t}\n\nWould it be useful behaviour if instead of exiting with an error it sent\na remote-object-info request for that single file ? \n\n\nThank you for your time in reviewing my proposal as well as considering\nmy application. I am excited to learn everything I can from git.\n\n\nThanks and Regards,\nSoutrik\n\n[1] : pull.2187.git.git.1770293021383.gitgitgadget@gmail.com\n[2] : 20260209172445.39536-1-valusoutrik@gmail.com\n[3] : 20260225190306.39358-1-valusoutrik@gmail.com\n[4] : 20240628190503.67389-1-eric.peijian@gmail.com\n[5] : 20220728230210.2952731-1-calvinwan@google.com\n"}]}