{"thread":{"id":"65227","subject":"[GSoC] Proposal: Complete and extend the remote-object-info command for git cat-file","startedAt":"2026-03-13T10:17:37Z","lastAt":"2026-04-12T14:41:24Z","messageCount":10,"participants":["Pablo","Chandra Pratap","Christian Couder","Pablo Sabater","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"538869","messageId":"CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com","threadId":"65227","inReplyTo":null,"subject":"[GSoC] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Pablo","fromEmail":"pabloosabaterr@gmail.com","sentAt":"2026-03-13T10:17:25Z","receivedAt":"2026-03-13T10:17:37Z","isPatch":false,"body":"## Synopsis\n\nThis project finishes Eric Ju's work on `remote-object-info` for `git\ncat-file --batch-command` [1], resolves the pending feedback from\nJunio Hamano [2] and Jeff King [3] [4] [5], and extends support for\n`%(objecttype)`.\n\nExpected project size: 350 hours (Medium)\n## About Me and Contact\n\nName: Pablo Sabater Jiménez (he/him)\n\nAge: 19\n\nEducation: Currently on my second Computer Science year at University\nof Murcia, Spain\n\nLocation: Murcia, Spain (CET, UTC+1)\n\nLanguages: C (solid), shell(bash) (good)\n\nTools: git(proficient)\n\nI've checked that I'm eligible for GSoC 2026.\n\nEmail: pabloosabaterr@gmail.com\nGitHub: https://github.com/pabloosabaterr\n\n## Relevant Projects\n\n- 16 bit CPU emulator. Good example of C programming.\n\n  cpu: https://github.com/pabloosabaterr/CPU16\n\n- Compiler. Good example of working on bigger projects.\n\n  compiler: https://github.com/pabloosabaterr/Orn\n\n## Pre-GSoC Work\n\n### Introduction\n\n**[GSoC] Introduction Pablo Sabater**\n\nhttps://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com\n\nA mailing list thread where I introduced myself to the git community.\n### Microproject\n\n**[GSoC PATCH v4] t9200: replace test -f/-d with modern path helpers**\n\nhttps://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n\nMerged to `next` on 2026-03-12 at 8500bdf172. Replaces `test -f` with\nhelper `test_path_is_file`, which makes debugging failing tests easier\nwith better reporting.\nAs suggested as microproject.\n\n### Other contributions\n\n**[GSoC PATCH v2] test-lib: print escape sequence names**\n\nhttps://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n\nWill merge to `next`, in failed expected/actual checks printing, the\nescape sequences were shown as their octal code. This patch fixes that\nto print the actual escape sequence name, adds tests, and updates the\nexpected output.\n\n**[GSoC PATCH] t9200: handle missing CVS with skip_all**\n\nhttps://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n\nMerged to `next` on 2026-03-12 at 8500bdf172, wraps CVS setup in a\nskip_all for clearer failure reporting and moves Git initialization\ninto its own test_expect_success.\n\n**[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to batch-command**\n\nhttps://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\nWhile testing Eric's v11 I've found and reported a new bug. On\n`remote-object-info` when it's preceded by a local query, `data->type`\nisn't being cleared. Causing it to return the wrong type.\n\nI have also studied the documentation provided and Eric Ju's work from\nv0 to v11 including all the feedback he got up to March 2025, the\nfeedback he got from Junio Hamano and Jeff King, taking notes about\nwhat's left to be done and what else I can contribute to the already\nproposed project. That's how I've identified everything that I will\naddress on the Problem, Solution and Timeline sections.\n\nI built Eric Ju's v11 and tested the bugs reported to his patch [5],\nI've confirmed the segfault and the `die()`, and found a new one:\n- When a local `info` runs before `remote-object-info` sharing the\nsame format string, `data->type` isn't being cleared. A blob queried\nremotely after a local commit, `data->type` for blob becomes 'commit'\nwith no error. I reported it on the mailing list [6].\n\nI attempted to test rebasing Eric Ju's v11 to master and got conflicts\non 4 out of the 8 commits:\n- `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n        - `t/t1006-cat-file.sh`\n- `d918f720d8` fetch-pack: refactor packet writing.\n        - `fetch-pack.c`\n- `2daf9ed803` transport: add client support for object-info.\n        - `Makefile`\n- `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n        - `object-file.c`, `object-store-ll.h` (deleted).\n\nI'm being active on the mailing list and learning the Git flow of work\nand from the feedback I've received from the maintainers (Junio) from\nmy patches.\n\nFollowing the project guidelines, I haven't done anything on the\nproject that could step on other candidates' work before being\naccepted, and instead I'm focusing on understanding the project and\nits needs, and independent patches that will make the Git project more\nfamiliar and understandable to me.\n\n## Availability\n\nMy classes end the first week of May. From then until September I\nwon't have any classes which leaves me free to fully focus on the\nproject. I can dedicate 8+ hours each day, and for sure 40 hours a\nweek.\n\n## The Problem\n\nGit's partial clone allows cloning repositories without downloading\nall objects (blobs, trees, ...). These objects are fetched on demand\nfrom the remote when needed. However, when a user needs metadata about\nthese remote objects (size, type, hash, ...), Git has no efficient way\nof doing this without downloading all the object content.\n\n The server side support for `object-info` protocol was implemented by\nCalvin Wan in 2021. Eric Ju built the client-side `remote-object-info`\nfor `cat-file --batch-command`. Eric Ju's work remains unmerged after\nv11 because of these issues:\n\n - The format validation uses `strstr()` which only checks for\n`%(objectsize)`. This causes two different errors:\n   - Atoms that `expand_atom()` recognizes but the remote doesn't\n(`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when\naccessing `data->type` it only contains garbage, causing segfault. as\nJeff King noted [3].\n   - Unknown atoms by `expand_atom()`, returns 0, calling\n`strbuf_expand_bad_format` on `expand_format()`, which calls `die()`,\nas Jeff King found [3].\n   Both cases block the command, including local `info` queries if the\nsame format string is shared. Unsupported remote placeholders should\nreturn an empty string, matching how `for-each-ref` returns empty for\nknown, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n\n - When local and remote queries are mixed, `data->type` is not being\ncleared between commands. `remote-object-info` returns the wrong type\ndata from a previous local query [6].\n\n - Style and code issues marked by Junio Hamano [2] and Jeff King [3]\n[5] are still undone.\n   - comment style.\n   - `#define` formatting.\n   - line length.\n   - misleading error messages.\n   - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n   - if/else invert at `get_remote_info()`.\n - `%(objecttype)` is not yet supported on either client or server side.\n\n## The Solution\n\nThere are two main goals:\n\n### Goal 1: Rebase and finish Eric's work\n\nStarting from where Eric Ju left off, I will rebase it on top of the\ncurrent `master` branch and address the feedback left to do:\n- Fix style in comments, `#define` formatting and line length.\n- Fix misleading error message in the overflow check.\n- Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n- Invert if/else on `get_remote_info()` to keep the small block first\n(the error one) as Junio suggested.\n#### Replace `strstr()` format validation with allow_list in `expand_atom()`\n\n`strstr()` isn't enough to fully validate the placeholders, it only\nsearches for `%(objectsize)` and unsupported placeholders cause\nsegfaults. The fix is to refactor the validation with an allow_list in\n`expand_atom()`. But why `expand_atom()` when Jeff King suggested\n`expand_atom()` or `expand_format()` [4] ?\n- There are two cases, first, inside `expand_atom()` before returning\n(segfault) and second, calls `die()` when `expand_atom()` returns 0.\n  Placing the `allow_list` at the top of `expand_atom()` prevents both\nerrors, on remote mode, append nothing to `sb` and return 1, accessing\n`data->type` won't cause segfault and prevents `expand_format()` from\nreaching `die()`.\n  As extra safety, initializing `data->type` to `OBJ_BAD` and check\nfor `NULL` from `type_name()` makes it that even without `allow_list`,\nuninitialized data doesn't cause a segfault.\n  At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the\nallow_list. Goal 2 will bring `%(objecttype)` support.\n### Goal 2: Adding `%(objecttype)`\n\nfollowing what Calvin Wan did in 2021 for `%(objectsize)`, v2 protocol\nneeds to be extended on the server side to support the new\n`%(objecttype)` placeholder:\n- extend `object_info_advertise()` at `serve.c`\n- add .type to `requested_info` struct at `serve.c`\n- support `type` in `cap_object_info()` at `protocol-caps.c`\n- look for type at `send_info()` at `protocol-caps.c`\n\nfollowing object-info protocol docs [7] it should look like:\n```\n  attrs = \"size\" SP \"type\"\n  obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n  obj-info = obj-id SP obj-size SP obj-type\n  info = PKT-LINE(attrs LF)\n        *PKT-LINE(obj-info LF)\n```\n\n`%(objecttype)` needs to be added to the `allow_list`. Client side\nneeds to learn to ask for `%(objecttype)` from remote, parse what has\nbeen received and fill `expand_data` with the actual type. This makes\nit return the object type instead of the empty string returned while\nit was unsupported.\n\nDefault format evolves to `%(objectname) %(objecttype) %(objectsize)`.\nTest and document new placeholder support and server side extension.\n\n#### Backward Compatibility\n\nThere are four possible scenarios to happen between client and server:\n1. The server doesn't know type (new client but old server):\n\n   After receiving the server capabilities, a client will only request\nwhat the server advertises. The `allow_list` would handle this,\nreturning an empty string when the server doesn't support it.\n2. The server knows type but the client doesn't (new server but old client):\n\n   Following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\nkeys\", it will ignore type, and request only the known capabilities.\n3. Both know type (new client and new server):\n\n   Server advertises type, client requests it and gets the type data.\n4. Both know type but protocol middleware doesn't (new client, new\nserver but old middleware):\n\n   If a server advertises type but client doesn't receive type, a\nclient won't ask for anything unadvertised, if a client asks for type\nbut the server doesn't receive it, it will only return the known\ncapabilities.\n\n**performance considerations**\n\nTo get an object type, we have to look only at the header, to get the\nsize `oid_object_info()` at `object-file.c` is being called which\nalready returns the object type in the same call. Sending the string\nwith the type will only be, worst case scenario 6 bytes for the\n\"commit\" string.\n## Timeline\n\nI've designed this to work with enough time so final work can be\nshorter than what's said here\n\nMay 1-24: Community Bonding\n- Talk and meet with mentor that I'm assigned with, to get feedback\nabout my proposal, how I will report my progress apart from the code\nsubmitted and possible blogs, and tips and tricks to work better at\nGit.\n- Confirm with mentor that the `allow_list` approach is still the best option.\n- Draft commits structure.\n\nWeek 1-2: (May 26 - June 8)\n- Rebase Eric Ju's  v11 on top of current `master`.\n- Work on style fixes: comments, `#define` formatting, line length.\n- Fix the wrong error message in the overflow check.\n- Add missing check `count > MAX_ALLOWED_OBJ_LIMIT` after `split_cmdline()`.\n- Invert if/else in `get_remote_info()`.\n- Send first patch.\n\nWeek 3-4: (June 9 - June 22)\n- Implement `allow_list` in `expand_atom()` using `is_atom()` in remote-mode.\n- Initialize `data->type` to `OBJ_BAD` and add null check at `type_name()`.\n- Implement empty string return for unsupported placeholders.\n- Tests for supported placeholders, unsupported, mix, and the intermix\ncase `info` + `remote-object-info` with the same format string.\n- Work with feedback from the first patch.\n\nWeek 5-6: (June 23 - July 6):\n- Continue with review feedback.\n- Goal 1 should be polished or close to the final form.\n- Prepare the midterm report.\n\nMidterm evaluation (July 7 - 11) as specified on GSoC timeline docs\n- Goal 1 submitted and keep work with feedback.\n\nWeek 7-8: (July 14 - July 27)\n- Begin Goal 2.\n- Extend server side v2 protocol to serve `%(objecttype)`, following\n`%(objectsize)` structure.\n- Test server side.\n\nWeek 9-10: (July 28 - August 10)\n- Add `%(objecttype)` to the `allow_list` from Goal 1.\n- Extend client side to ask for `%(objecttype)` from remote on `object-info`.\n- Parse server answer and fill `expand_data` with the actual type.\n- End to end tests and documentation.\n- Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n- Send patch series.\n\nWeek 11-12: (August 11 - August 24)\n- Work with Goal 2 feedback from the patches.\n- Polish everything, all tests pass, good test coverage, no\nstyle/comment mistakes.\n- Final documentation review.\n- Prepare for final evaluation.\n\nFinal evaluation (August 18-24) as specified on GSoC timeline docs\n\n### Additional objectives\n\nIf there is enough time, or for future work after the project. I've\nsome ideas on how this could evolve:\n#### More placeholders support\nI've checked that Eric's v11 patch only supports `%(objectsize)` on\nserver side, but on the client side there are other placeholders that\ncan be added too. with the `allow_list` and having Goal 2 implemented\nadding more placeholders becomes trivial.\n\n- `%(objectsize:disk)`: Returns the size on the disk (compressed or as\na delta) instead of returning the uncompressed size that\n`%(objectsize)` does. To do this, the server would need to send what's\nthe actual size on disk data.\n\n- `%(deltabase)`: Returns the delta base object OID. non delta objects\nreturn zero OID as it does on local.\n\n#### Returning missing blobs from a tree ordered\nIn a partial clone, someone might want to know what blobs are missing\ninside a concrete tree and their size before fetching them.\nThe idea is to build on top of `remote-object-info`:\nGiven a tree hash, return the missing blobs (inside that tree) ordered by size.\n\nThanks for reading my proposal and considering my application. I'm\nvery excited about this opportunity,\nPablo\n\n[1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\"Eric Ju's v11 patch\"\n\n[2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\nHamano feedback\"\n\n[3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n\"Jeff King feedback\"\n\n[4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n\"options for strstr() by Jeff King\"\n\n[5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n\"Jeff King follow-up\"\n\n[6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\"data->type not being cleared bug\"\n\n[7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n\"object-info protocol docs\"\n"},{"id":"538953","messageId":"CA+J6zkROsbkr6mWQrEhnswtb4sOh+UMO+bt3P-5XDiAjhtcsMg@mail.gmail.com","threadId":"65227","inReplyTo":"CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com","subject":"Re: [GSoC] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Chandra Pratap","fromEmail":"chandrapratap3519@gmail.com","sentAt":"2026-03-14T05:58:47Z","receivedAt":"2026-03-14T05:59:14Z","isPatch":false,"body":"Hi Pablo,\n\nOn Fri, 13 Mar 2026 at 15:47, Pablo <pabloosabaterr@gmail.com> wrote:\n>\n> ## Synopsis\n>\n> This project finishes Eric Ju's work on `remote-object-info` for `git\n> cat-file --batch-command` [1], resolves the pending feedback from\n> Junio Hamano [2] and Jeff King [3] [4] [5], and extends support for\n> `%(objecttype)`.\n>\n> Expected project size: 350 hours (Medium)\n> ## About Me and Contact\n>\n> Name: Pablo Sabater Jiménez (he/him)\n>\n> Age: 19\n>\n> Education: Currently on my second Computer Science year at University\n> of Murcia, Spain\n>\n> Location: Murcia, Spain (CET, UTC+1)\n>\n> Languages: C (solid), shell(bash) (good)\n>\n> Tools: git(proficient)\n>\n> I've checked that I'm eligible for GSoC 2026.\n>\n> Email: pabloosabaterr@gmail.com\n> GitHub: https://github.com/pabloosabaterr\n>\n> ## Relevant Projects\n>\n> - 16 bit CPU emulator. Good example of C programming.\n>\n>   cpu: https://github.com/pabloosabaterr/CPU16\n>\n> - Compiler. Good example of working on bigger projects.\n>\n>   compiler: https://github.com/pabloosabaterr/Orn\n>\n\nThanks for your interest in contributing to Git this GSoC!\n\n> ## Pre-GSoC Work\n>\n> ### Introduction\n>\n> **[GSoC] Introduction Pablo Sabater**\n>\n> https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com\n>\n> A mailing list thread where I introduced myself to the git community.\n\nNit: Could use a newline here.\n\n> ### Microproject\n>\n> **[GSoC PATCH v4] t9200: replace test -f/-d with modern path helpers**\n>\n> https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n>\n> Merged to `next` on 2026-03-12 at 8500bdf172. Replaces `test -f` with\n> helper `test_path_is_file`, which makes debugging failing tests easier\n> with better reporting.\n> As suggested as microproject.\n>\n> ### Other contributions\n>\n> **[GSoC PATCH v2] test-lib: print escape sequence names**\n>\n> https://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n>\n> Will merge to `next`, in failed expected/actual checks printing, the\n> escape sequences were shown as their octal code. This patch fixes that\n> to print the actual escape sequence name, adds tests, and updates the\n> expected output.\n>\n> **[GSoC PATCH] t9200: handle missing CVS with skip_all**\n>\n> https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n>\n> Merged to `next` on 2026-03-12 at 8500bdf172, wraps CVS setup in a\n> skip_all for clearer failure reporting and moves Git initialization\n> into its own test_expect_success.\n>\n> **[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to batch-command**\n>\n> https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n>\n> While testing Eric's v11 I've found and reported a new bug. On\n> `remote-object-info` when it's preceded by a local query, `data->type`\n> isn't being cleared. Causing it to return the wrong type.\n>\n> I have also studied the documentation provided and Eric Ju's work from\n> v0 to v11 including all the feedback he got up to March 2025, the\n> feedback he got from Junio Hamano and Jeff King, taking notes about\n> what's left to be done and what else I can contribute to the already\n> proposed project. That's how I've identified everything that I will\n> address on the Problem, Solution and Timeline sections.\n>\n> I built Eric Ju's v11 and tested the bugs reported to his patch [5],\n> I've confirmed the segfault and the `die()`, and found a new one:\n> - When a local `info` runs before `remote-object-info` sharing the\n> same format string, `data->type` isn't being cleared. A blob queried\n> remotely after a local commit, `data->type` for blob becomes 'commit'\n> with no error. I reported it on the mailing list [6].\n>\n> I attempted to test rebasing Eric Ju's v11 to master and got conflicts\n> on 4 out of the 8 commits:\n> - `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n>         - `t/t1006-cat-file.sh`\n> - `d918f720d8` fetch-pack: refactor packet writing.\n>         - `fetch-pack.c`\n> - `2daf9ed803` transport: add client support for object-info.\n>         - `Makefile`\n> - `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n>         - `object-file.c`, `object-store-ll.h` (deleted).\n>\n> I'm being active on the mailing list and learning the Git flow of work\n> and from the feedback I've received from the maintainers (Junio) from\n> my patches.\n>\n> Following the project guidelines, I haven't done anything on the\n> project that could step on other candidates' work before being\n> accepted, and instead I'm focusing on understanding the project and\n> its needs, and independent patches that will make the Git project more\n> familiar and understandable to me.\n\nGreat work! It would help if you could split the description of your patches\ninto Status, Description, Comments, etc. It helps a lot when reviewing the\nproposal.\n\n>\n> ## Availability\n>\n> My classes end the first week of May. From then until September I\n> won't have any classes which leaves me free to fully focus on the\n> project. I can dedicate 8+ hours each day, and for sure 40 hours a\n> week.\n>\n> ## The Problem\n>\n> Git's partial clone allows cloning repositories without downloading\n> all objects (blobs, trees, ...). These objects are fetched on demand\n> from the remote when needed. However, when a user needs metadata about\n> these remote objects (size, type, hash, ...), Git has no efficient way\n> of doing this without downloading all the object content.\n>\n>  The server side support for `object-info` protocol was implemented by\n> Calvin Wan in 2021. Eric Ju built the client-side `remote-object-info`\n> for `cat-file --batch-command`.\n\nThis part is likely more relevant in the 'Synopsis' section up top. It provides\nimportant context that helps the reader tune their expectations for the rest\nof the proposal.\n\nFrom my experience, a good rule of thumb when writing a proposal is to\nassume the reader doesn't know anything about the project or the problem\nit tackles beforehand.\n\n> Eric Ju's work remains unmerged after\n> v11 because of these issues:\n>\n>  - The format validation uses `strstr()` which only checks for\n> `%(objectsize)`. This causes two different errors:\n>    - Atoms that `expand_atom()` recognizes but the remote doesn't\n> (`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when\n> accessing `data->type` it only contains garbage, causing segfault. as\n> Jeff King noted [3].\n\nGrammar nit: should be 'garbage causing segfault, as Jeff King noted[3].'\nThe sentence could also use some restructuring for better clarity.\n\nIt is great that you've referenced the relevant discussion thread here.\n\n>    - Unknown atoms by `expand_atom()`, returns 0, calling\n> `strbuf_expand_bad_format` on `expand_format()`, which calls `die()`,\n> as Jeff King found [3].\n>    Both cases block the command, including local `info` queries if the\n> same format string is shared. Unsupported remote placeholders should\n> return an empty string, matching how `for-each-ref` returns empty for\n> known, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n>\n>  - When local and remote queries are mixed, `data->type` is not being\n> cleared between commands. `remote-object-info` returns the wrong type\n> data from a previous local query [6].\n>\n\nYou've mentioned the outstanding issues and their implications for the end user.\nGood work.\n\n>  - Style and code issues marked by Junio Hamano [2] and Jeff King [3]\n> [5] are still undone.\n>    - comment style.\n>    - `#define` formatting.\n>    - line length.\n>    - misleading error messages.\n>    - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n>    - if/else invert at `get_remote_info()`.\n>  - `%(objecttype)` is not yet supported on either client or server side.\n>\n> ## The Solution\n>\n> There are two main goals:\n>\n> ### Goal 1: Rebase and finish Eric's work\n>\n> Starting from where Eric Ju left off, I will rebase it on top of the\n> current `master` branch and address the feedback left to do:\n> - Fix style in comments, `#define` formatting and line length.\n> - Fix misleading error message in the overflow check.\n> - Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n> - Invert if/else on `get_remote_info()` to keep the small block first\n> (the error one) as Junio suggested.\n> #### Replace `strstr()` format validation with allow_list in `expand_atom()`\n\nNit: Could use a newline here.\n\n>\n> `strstr()` isn't enough to fully validate the placeholders, it only\n> searches for `%(objectsize)` and unsupported placeholders cause\n> segfaults. The fix is to refactor the validation with an allow_list in\n> `expand_atom()`.\n\nIt is great if this is your idea, but if not, it would help to credit the\nperson who suggested this and link to the relevant discussion, if\napplicable.\n\n> But why `expand_atom()` when Jeff King suggested\n> `expand_atom()` or `expand_format()` [4] ?\n> - There are two cases, first, inside `expand_atom()` before returning\n> (segfault) and second, calls `die()` when `expand_atom()` returns 0.\n>   Placing the `allow_list` at the top of `expand_atom()` prevents both\n> errors, on remote mode, append nothing to `sb` and return 1, accessing\n> `data->type` won't cause segfault and prevents `expand_format()` from\n> reaching `die()`.\n>   As extra safety, initializing `data->type` to `OBJ_BAD` and check\n> for `NULL` from `type_name()` makes it that even without `allow_list`,\n> uninitialized data doesn't cause a segfault.\n>   At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the\n> allow_list. Goal 2 will bring `%(objecttype)` support.\n> ### Goal 2: Adding `%(objecttype)`\n\nNit: Newline here as well.\n\n>\n> following what Calvin Wan did in 2021 for `%(objectsize)`, v2 protocol\n\nGrammar nit: [F]ollowing.\n\n> needs to be extended on the server side to support the new\n> `%(objecttype)` placeholder:\n> - extend `object_info_advertise()` at `serve.c`\n> - add .type to `requested_info` struct at `serve.c`\n> - support `type` in `cap_object_info()` at `protocol-caps.c`\n> - look for type at `send_info()` at `protocol-caps.c`\n>\n> following object-info protocol docs [7] it should look like:\n\nHere as well.\n\n> ```\n>   attrs = \"size\" SP \"type\"\n>   obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n>   obj-info = obj-id SP obj-size SP obj-type\n>   info = PKT-LINE(attrs LF)\n>         *PKT-LINE(obj-info LF)\n> ```\n>\n> `%(objecttype)` needs to be added to the `allow_list`. Client side\n> needs to learn to ask for `%(objecttype)` from remote, parse what has\n> been received and fill `expand_data` with the actual type. This makes\n> it return the object type instead of the empty string returned while\n> it was unsupported.\n>\n> Default format evolves to `%(objectname) %(objecttype) %(objectsize)`.\n> Test and document new placeholder support and server side extension.\n>\n\nMakes sense.\n\n> #### Backward Compatibility\n>\n> There are four possible scenarios to happen between client and server:\n> 1. The server doesn't know type (new client but old server):\n>\n>    After receiving the server capabilities, a client will only request\n> what the server advertises. The `allow_list` would handle this,\n> returning an empty string when the server doesn't support it.\n> 2. The server knows type but the client doesn't (new server but old client):\n>\n>    Following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\n> keys\", it will ignore type, and request only the known capabilities.\n> 3. Both know type (new client and new server):\n>\n>    Server advertises type, client requests it and gets the type data.\n> 4. Both know type but protocol middleware doesn't (new client, new\n> server but old middleware):\n>\n>    If a server advertises type but client doesn't receive type, a\n> client won't ask for anything unadvertised, if a client asks for type\n> but the server doesn't receive it, it will only return the known\n> capabilities.\n>\n\nThis section makes sense as well, could use better formatting though.\n\n> **performance considerations**\n>\n> To get an object type, we have to look only at the header, to get the\n> size `oid_object_info()` at `object-file.c` is being called which\n> already returns the object type in the same call. Sending the string\n> with the type will only be, worst case scenario 6 bytes for the\n> \"commit\" string.\n> ## Timeline\n>\n\nNit: newline.\n\n> I've designed this to work with enough time so final work can be\n> shorter than what's said here\n>\n> May 1-24: Community Bonding\n> - Talk and meet with mentor that I'm assigned with, to get feedback\n> about my proposal, how I will report my progress apart from the code\n> submitted and possible blogs, and tips and tricks to work better at\n> Git.\n> - Confirm with mentor that the `allow_list` approach is still the best option.\n> - Draft commits structure.\n\nIt would also be helpful if you continue working on your patches that haven't\nbeen merged yet from your pre-GSoC efforts. The goal of Community\nBonding Period is to interact with the wider community as much as possible,\nand what better way to do that other than engaging through patches.\n\nAlso, GSoC/Git requires you to write weekly blog posts detailing your work,\nwhat's holding you back, etc. So it's good if you use this time to set up your\nblog, if you don't have one already.\n\n>\n> Week 1-2: (May 26 - June 8)\n> - Rebase Eric Ju's  v11 on top of current `master`.\n> - Work on style fixes: comments, `#define` formatting, line length.\n> - Fix the wrong error message in the overflow check.\n> - Add missing check `count > MAX_ALLOWED_OBJ_LIMIT` after `split_cmdline()`.\n> - Invert if/else in `get_remote_info()`.\n\nThese four points are specifics of how you're going to tackle the\n'Style Issues' problem\nyou mentioned above. I don't think there's any benefit in reiterating them here.\n\nA single 'Fix the style and code issues.' or something similar would be better.\n\n> - Send first patch.\n>\n> Week 3-4: (June 9 - June 22)\n> - Implement `allow_list` in `expand_atom()` using `is_atom()` in remote-mode.\n> - Initialize `data->type` to `OBJ_BAD` and add null check at `type_name()`.\n> - Implement empty string return for unsupported placeholders.\n> - Tests for supported placeholders, unsupported, mix, and the intermix\n> case `info` + `remote-object-info` with the same format string.\n> - Work with feedback from the first patch.\n\nAgain, specifics of the implementation plan don't need reiteration.\n\n>\n> Week 5-6: (June 23 - July 6):\n> - Continue with review feedback.\n> - Goal 1 should be polished or close to the final form.\n> - Prepare the midterm report.\n>\n> Midterm evaluation (July 7 - 11) as specified on GSoC timeline docs\n> - Goal 1 submitted and keep work with feedback.\n\nYou could probably dedicate this time to start working on Goal 2.\nAddressing feedback is something that occurs spontaneously and\ndoesn't need dedicated slots in your timeline.\n\n> Week 7-8: (July 14 - July 27)\n> - Begin Goal 2.\n> - Extend server side v2 protocol to serve `%(objecttype)`, following\n> `%(objectsize)` structure.\n> - Test server side.\n>\n> Week 9-10: (July 28 - August 10)\n> - Add `%(objecttype)` to the `allow_list` from Goal 1.\n> - Extend client side to ask for `%(objecttype)` from remote on `object-info`.\n> - Parse server answer and fill `expand_data` with the actual type.\n> - End to end tests and documentation.\n> - Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n> - Send patch series.\n>\n> Week 11-12: (August 11 - August 24)\n> - Work with Goal 2 feedback from the patches.\n> - Polish everything, all tests pass, good test coverage, no\n> style/comment mistakes.\n> - Final documentation review.\n> - Prepare for final evaluation.\n>\n> Final evaluation (August 18-24) as specified on GSoC timeline docs\n>\n> ### Additional objectives\n>\n> If there is enough time, or for future work after the project. I've\n> some ideas on how this could evolve:\n> #### More placeholders support\n> I've checked that Eric's v11 patch only supports `%(objectsize)` on\n> server side, but on the client side there are other placeholders that\n> can be added too. with the `allow_list` and having Goal 2 implemented\n> adding more placeholders becomes trivial.\n>\n> - `%(objectsize:disk)`: Returns the size on the disk (compressed or as\n> a delta) instead of returning the uncompressed size that\n> `%(objectsize)` does. To do this, the server would need to send what's\n> the actual size on disk data.\n>\n> - `%(deltabase)`: Returns the delta base object OID. non delta objects\n> return zero OID as it does on local.\n>\n> #### Returning missing blobs from a tree ordered\n> In a partial clone, someone might want to know what blobs are missing\n> inside a concrete tree and their size before fetching them.\n> The idea is to build on top of `remote-object-info`:\n> Given a tree hash, return the missing blobs (inside that tree) ordered by size.\n>\n> Thanks for reading my proposal and considering my application. I'm\n> very excited about this opportunity,\n> Pablo\n>\n> [1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n> \"Eric Ju's v11 patch\"\n>\n> [2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\n> Hamano feedback\"\n>\n> [3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n> \"Jeff King feedback\"\n>\n> [4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n> \"options for strstr() by Jeff King\"\n>\n> [5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n> \"Jeff King follow-up\"\n>\n> [6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n> \"data->type not being cleared bug\"\n>\n> [7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n> \"object-info protocol docs\"\n\nOverall, great work on the proposal so far! Other than a few stylistic\nmishaps, the proposal\nlooks pretty strong already.\n\nYou should upload your proposal on the GSoC website and add the link to it here.\nThe proposal can be then updated later as many times as you like.\n\nRegards,\nChandra.\n"},{"id":"538985","messageId":"CAN5EUNQdNtPq1mEBUXOjRJ_t2n=cSUS9dz+HUfqbFjrjZVoGLQ@mail.gmail.com","threadId":"65227","inReplyTo":"CA+J6zkROsbkr6mWQrEhnswtb4sOh+UMO+bt3P-5XDiAjhtcsMg@mail.gmail.com","subject":"Re: [GSoC] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Pablo","fromEmail":"pabloosabaterr@gmail.com","sentAt":"2026-03-14T18:31:37Z","receivedAt":"2026-03-14T18:31:52Z","isPatch":false,"body":"Hi Chandra, thanks a lot for the feedback! :)\n\n> You should upload your proposal on the GSoC website and add the link to it here.\n> The proposal can be then updated later as many times as you like.\n\nGSoC proposals opens March 16th, for now I'll send my v2 here and as\nsoon as I can I'll swap to GSoC website and send the link to the\nthread.\n\nTo avoid having you reread everything again this is what I've done from v1:\n\n  Moved context explanation from The Problem to Synopsis and\nAvailability below About Me and Contact.\n  Split Pre-GSoC patches into status (for code patches) and\ndescription to improve readability.\n  Added a code review and proposal thread to the Pre-GSoC section.\n  Added new lines where noted and fixed capitalization.\n  Correctly credited Jeff King for the allow_list idea and added new\n[8] for Calvin Wan's work.\n  Community bonding now includes continuing patches and setting up a blog.\n  Removed most of the duplicated iteration on the Timeline from The\nProblem. (feels a bit empty now tho).\n\nI paste here my v2 with the requested changes:\n\n## Synopsis\n\nGit's partial clone allows cloning repositories without downloading\nall objects (blobs, trees, ...). These objects are fetched on demand\nfrom the remote when needed. However, when a user needs metadata about\nthese remote objects (size, type, hash, ...), Git has no efficient way\nof doing this without downloading all the object content.\n\nThe server side support for `object-info` protocol was implemented by\nCalvin Wan in 2021 [8]. Eric Ju built the client-side\n`remote-object-info` for `cat-file --batch-command`.\n\nThis project finishes Eric Ju's work on `remote-object-info` for `git\ncat-file --batch-command` [1], resolves the pending feedback from\nJunio Hamano [2] and Jeff King [3] [4] [5], and extends support for\n`%(objecttype)`.\n\nExpected project size: 350 hours (Medium)\n\n## About Me and Contact\n\nName: Pablo Sabater Jiménez (he/him)\n\nAge: 19\n\nEducation: Currently on my second Computer Science year at University\nof Murcia, Spain\n\nLocation: Murcia, Spain (CET, UTC+1)\n\nLanguages: C (solid), shell(bash) (good)\n\nTools: git(proficient)\n\nI've checked that I'm eligible for GSoC 2026.\n\nEmail: pabloosabaterr@gmail.com\nGitHub: https://github.com/pabloosabaterr\n\n## Availability\n\nMy classes end the first week of May. From then until September I\nwon't have any classes which leaves me free to fully focus on the\nproject. I can dedicate 8+ hours each day, and for sure 40 hours a\nweek.\n\n## Relevant Projects\n\n- 16 bit CPU emulator. Good example of C programming.\n\n  cpu: https://github.com/pabloosabaterr/CPU16\n\n- Compiler. Good example of working on bigger projects.\n\n  compiler: https://github.com/pabloosabaterr/Orn\n\n## Pre-GSoC Work\n\n### Introduction\n\n**[GSoC] Introduction Pablo Sabater**\n\nhttps://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com\n\n**Description**: A mailing list thread where I introduced myself to\nthe git community.\n\n### Microproject\n\n**[GSoC PATCH v4] t9200: replace test -f/-d with modern path helpers**\n\nhttps://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n\n**Description**: Replaces `test -f` with helper `test_path_is_file`,\nwhich makes debugging failing tests easier with better reporting.\nAs suggested as microproject.\n\n### Other contributions\n\n**[GSoC PATCH v2] test-lib: print escape sequence names**\n\nhttps://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n\n**Status**: Will merge to `next`.\n\n**Description**: In failed expected/actual checks printing, the escape\nsequences were shown as their octal code. This patch fixes that to\nprint the actual escape sequence name, adds tests, and updates the\nexpected output.\n\n**[GSoC PATCH] t9200: handle missing CVS with skip_all**\n\nhttps://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n\n**Description**: wraps CVS setup in a skip_all for clearer failure\nreporting and moves Git initialization into its own\ntest_expect_success.\n\n**Re: [PATCH] gc: add git maintenance list command**\n\nhttps://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/\n\n**Description**: code review for a patch sent.\n\n**[GSoC] Proposal: Complete and extend remote-object-info for git cat-file**\n\nhttps://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/\n\n**Description**: Proposal draft thread.\n\n**[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to batch-command**\n\nhttps://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\n**Description**: While testing Eric's v11 I've found and reported a\nnew bug. On `remote-object-info` when it's preceded by a local query,\n`data->type` isn't being cleared. Causing it to return the wrong type.\n\nI have also studied the documentation provided and Eric Ju's work from\nv0 to v11 including all the feedback he got up to March 2025, the\nfeedback he got from Junio Hamano and Jeff King, taking notes about\nwhat's left to be done and what else I can contribute to the already\nproposed project. That's how I've identified everything that I will\naddress on the Problem, Solution and Timeline sections.\n\nI built Eric Ju's v11 and tested the bugs reported to his patch [5],\nI've confirmed the segfault and the `die()`, and found a new one:\n- When a local `info` runs before `remote-object-info` sharing the\nsame format string, `data->type` isn't being cleared. A blob queried\nremotely after a local commit, `data->type` for blob becomes 'commit'\nwith no error. I reported it on the mailing list [6].\n\nI attempted to test rebasing Eric Ju's v11 to master and got conflicts\non 4 out of the 8 commits:\n- `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n        - `t/t1006-cat-file.sh`\n- `d918f720d8` fetch-pack: refactor packet writing.\n        - `fetch-pack.c`\n- `2daf9ed803` transport: add client support for object-info.\n        - `Makefile`\n- `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n        - `object-file.c`, `object-store-ll.h` (deleted).\n\nI'm being active on the mailing list and learning the Git flow of work\nand from the feedback I've received from the maintainers (Junio) from\nmy patches.\n\nFollowing the project guidelines, I haven't done anything on the\nproject that could step on other candidates' work before being\naccepted, and instead I'm focusing on understanding the project and\nits needs, and independent patches that will make the Git project more\nfamiliar and understandable to me.\n\n## The Problem\n\nEric Ju's work remains unmerged after v11 because of these issues:\n\n - The format validation uses `strstr()` which only checks for\n`%(objectsize)`. This causes two different errors:\n   - Atoms that `expand_atom()` recognizes but the remote doesn't\n(`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when\naccessing `data->type` it only contains garbage, causing segfault, as\nJeff King noted [3].\n   - Unknown atoms by `expand_atom()`, returns 0, calling\n`strbuf_expand_bad_format` on `expand_format()`, which calls `die()`,\nas Jeff King found [3].\n   Both cases block the command, including local `info` queries if the\nsame format string is shared. Unsupported remote placeholders should\nreturn an empty string, matching how `for-each-ref` returns empty for\nknown, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n\n - When local and remote queries are mixed, `data->type` is not being\ncleared between commands. `remote-object-info` returns the wrong type\ndata from a previous local query [6].\n\n - Style and code issues marked by Junio Hamano [2] and Jeff King [3]\n[5] are still undone.\n   - comment style.\n   - `#define` formatting.\n   - line length.\n   - misleading error messages.\n   - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n   - if/else invert at `get_remote_info()`.\n - `%(objecttype)` is not yet supported on either client or server side.\n\n## The Solution\n\nThere are two main goals:\n\n### Goal 1: Rebase and finish Eric's work\n\nStarting from where Eric Ju left off, I will rebase it on top of the\ncurrent `master` branch and address the feedback left to do:\n- Fix style in comments, `#define` formatting and line length.\n- Fix misleading error message in the overflow check.\n- Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n- Invert if/else on `get_remote_info()` to keep the small block first\n(the error one) as Junio suggested.\n\n#### Replace `strstr()` format validation with allow_list in `expand_atom()`\n\n`strstr()` isn't enough to fully validate the placeholders, it only\nsearches for `%(objectsize)` and unsupported placeholders cause\nsegfaults. Jeff King noted [4] that the fix was to refactor the\nvalidation with an allow_list in `expand_atom()` or `expand_format()`.\nThe best option is to place the validation at `expand_atom()`, but why\n`expand_atom()` ?\n- There are two cases, first, inside `expand_atom()` before returning\n(segfault) and second, calls `die()` when `expand_atom()` returns 0.\n  Placing the `allow_list` at the top of `expand_atom()` prevents both\nerrors, on remote mode, append nothing to `sb` and return 1, accessing\n`data->type` won't cause segfault and prevents `expand_format()` from\nreaching `die()`.\n  As extra safety, initializing `data->type` to `OBJ_BAD` and check\nfor `NULL` from `type_name()` makes it that even without `allow_list`,\nuninitialized data doesn't cause a segfault.\n  At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the\nallow_list. Goal 2 will bring `%(objecttype)` support.\n\n### Goal 2: Adding `%(objecttype)`\n\nFollowing what Calvin Wan did in 2021 [8] for `%(objectsize)`, v2\nprotocol needs to be extended on the server side to support the new\n`%(objecttype)` placeholder:\n- extend `object_info_advertise()` at `serve.c`\n- add .type to `requested_info` struct at `serve.c`\n- support `type` in `cap_object_info()` at `protocol-caps.c`\n- look for type at `send_info()` at `protocol-caps.c`\n\nFollowing object-info protocol docs [7] it should look like:\n```\n  attrs = \"size\" SP \"type\"\n  obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n  obj-info = obj-id SP obj-size SP obj-type\n  info = PKT-LINE(attrs LF)\n        *PKT-LINE(obj-info LF)\n```\n\n`%(objecttype)` needs to be added to the `allow_list`. Client side\nneeds to learn to ask for `%(objecttype)` from remote, parse what has\nbeen received and fill `expand_data` with the actual type. This makes\nit return the object type instead of the empty string returned while\nit was unsupported.\n\nDefault format evolves to `%(objectname) %(objecttype) %(objectsize)`.\nTest and document new placeholder support and server side extension.\n\n#### Backward Compatibility\n\nThere are four possible scenarios to happen between client and server:\n\n1. **The server doesn't know type (new client but old server)**:\n\n   After receiving the server capabilities, a client will only request\nwhat the server advertises. The `allow_list` would handle this,\nreturning an empty string when the server doesn't support it.\n\n2. **The server knows type but the client doesn't (new server but old client)**:\n\n   Following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\nkeys\", it will ignore type, and request only the known capabilities.\n\n3. **Both know type (new client and new server)**:\n\n   Server advertises type, client requests it and gets the type data.\n\n4. **Both know type but protocol middleware doesn't (new client, new\nserver but old middleware)**:\n\n   If a server advertises type but client doesn't receive type, a\nclient won't ask for anything unadvertised, if a client asks for type\nbut the server doesn't receive it, it will only return the known\ncapabilities.\n\n**performance considerations**\n\nTo get an object type, we have to look only at the header, to get the\nsize `oid_object_info()` at `object-file.c` is being called which\nalready returns the object type in the same call. Sending the string\nwith the type will only be, worst case scenario 6 bytes for the\n\"commit\" string.\n\n## Timeline\n\nI've designed this to work with enough time so final work can be\nshorter than what's said here\n\nMay 1-24: Community Bonding\n- Keep working on my ongoing patches and new ones.\n- Talk and meet with mentor that I'm assigned with, to get feedback\nabout my proposal, how I will report my progress apart from the code\nsubmitted and possible blogs, and tips and tricks to work better at\nGit.\n- Confirm with mentor that the `allow_list` approach is still the best option.\n- Draft commits structure.\n- Setup a blog to keep track about how GSoC at Git is going.\n\nWeek 1-2: (May 26 - June 8)\n- Start Goal 1 fixes.\n- Fix style and code issues.\n\nWeek 3-4: (June 9 - June 22)\n- Start with Goal 1 implementations (allow_list approach).\n\nWeek 5-6: (June 23 - July 6):\n- Goal 1 should be polished or close to the final form.\n- Send patch series for Goal 1.\n- Start Goal 2.\n- Prepare the midterm report.\n\n**Midterm evaluation** (July 7 - 11) as specified on GSoC timeline docs\n- Goal 1 submitted.\n\nWeek 7-8: (July 14 - July 27)\n- Start with server side v2 protocol extension (`%(objecttype)`).\n\nWeek 9-10: (July 28 - August 10)\n- Add `%(objecttype)` to the `allow_list` from Goal 1.\n- Client side extension.\n- End to end tests and documentation.\n- Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n- Send patch series.\n\nWeek 11-12: (August 11 - August 24)\n- Goal 2 should be close to be done.\n- Polish everything, all tests pass, good test coverage, no\nstyle/comment issues.\n- Final documentation review.\n- Prepare for final evaluation.\n\n**Final evaluation** (August 18-24) as specified on GSoC timeline docs\n\n### Additional objectives\n\nIf there is enough time, or for future work after the project. I've\nsome ideas on how this could evolve:\n\n#### More placeholders support\n\nI've checked that Eric's v11 patch only supports `%(objectsize)` on\nserver side, but on the client side there are other placeholders that\ncan be added too. With the `allow_list` and having Goal 2 implemented,\nadding more placeholders becomes trivial.\n\n- `%(objectsize:disk)`: Returns the size on the disk (compressed or as\na delta) instead of returning the uncompressed size that\n`%(objectsize)` does. To do this, the server would need to send what's\nthe actual size on disk data.\n\n- `%(deltabase)`: Returns the delta base object OID. non delta objects\nreturn zero OID as it does on local.\n\n#### Returning missing blobs from a tree ordered\n\nIn a partial clone, someone might want to know what blobs are missing\ninside a concrete tree and their size before fetching them.\nThe idea is to build on top of `remote-object-info`:\nGiven a tree hash, return the missing blobs (inside that tree) ordered by size.\n\nThanks for reading my proposal and considering my application. I'm\nvery excited about this opportunity,\nPablo\n\n[1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\"Eric Ju's v11 patch\"\n\n[2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\nHamano feedback\"\n\n[3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n\"Jeff King feedback\"\n\n[4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n\"options for strstr() by Jeff King\"\n\n[5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n\"Jeff King follow-up\"\n\n[6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\"data->type not being cleared bug\"\n\n[7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n\"object-info protocol docs\"\n\n[8]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n\"Calvin Wan's patch series\"\n\n---\n\nAgain, thanks a lot for the feedback.\n"},{"id":"539017","messageId":"CA+J6zkSE1ek2einA=CimH0TNoR8Ou_-acp88hhtC5qV09-Xu5w@mail.gmail.com","threadId":"65227","inReplyTo":"CAN5EUNQdNtPq1mEBUXOjRJ_t2n=cSUS9dz+HUfqbFjrjZVoGLQ@mail.gmail.com","subject":"Re: [GSoC] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Chandra Pratap","fromEmail":"chandrapratap3519@gmail.com","sentAt":"2026-03-15T09:20:58Z","receivedAt":"2026-03-15T09:21:27Z","isPatch":false,"body":"On Sun, 15 Mar 2026 at 00:01, Pablo <pabloosabaterr@gmail.com> wrote:\n>\n> Hi Chandra, thanks a lot for the feedback! :)\n>\n> > You should upload your proposal on the GSoC website and add the link to it here.\n> > The proposal can be then updated later as many times as you like.\n>\n> GSoC proposals opens March 16th, for now I'll send my v2 here and as\n> soon as I can I'll swap to GSoC website and send the link to the\n> thread.\n\nI don't think you need to do this, just make sure you include the link when\nyou send your revised proposals in the future.\n\n> To avoid having you reread everything again this is what I've done from v1:\n>\n>   Moved context explanation from The Problem to Synopsis and\n> Availability below About Me and Contact.\n>   Split Pre-GSoC patches into status (for code patches) and\n> description to improve readability.\n>   Added a code review and proposal thread to the Pre-GSoC section.\n>   Added new lines where noted and fixed capitalization.\n>   Correctly credited Jeff King for the allow_list idea and added new\n> [8] for Calvin Wan's work.\n>   Community bonding now includes continuing patches and setting up a blog.\n\nQuickly skimmed over the new proposal and it definitely looks better\nnow. Great job!\n\n>   Removed most of the duplicated iteration on the Timeline from The\n> Problem. (feels a bit empty now tho).\n\nThis is fine because you've already discussed the relevant details in earlier\nsections.\n\nYou could think of fleshing it out with new information, but duplicating details\njust for the sake of a 'fuller' proposal waters down the impact of the rest of\nyour work. There isn't a word count requirement after all :)\n\n>\n> I paste here my v2 with the requested changes:\n>\n> ## Synopsis\n>\n> Git's partial clone allows cloning repositories without downloading\n> all objects (blobs, trees, ...). These objects are fetched on demand\n> from the remote when needed. However, when a user needs metadata about\n> these remote objects (size, type, hash, ...), Git has no efficient way\n> of doing this without downloading all the object content.\n>\n> The server side support for `object-info` protocol was implemented by\n> Calvin Wan in 2021 [8]. Eric Ju built the client-side\n> `remote-object-info` for `cat-file --batch-command`.\n>\n> This project finishes Eric Ju's work on `remote-object-info` for `git\n> cat-file --batch-command` [1], resolves the pending feedback from\n> Junio Hamano [2] and Jeff King [3] [4] [5], and extends support for\n> `%(objecttype)`.\n>\n> Expected project size: 350 hours (Medium)\n>\n> ## About Me and Contact\n>\n> Name: Pablo Sabater Jiménez (he/him)\n>\n> Age: 19\n>\n> Education: Currently on my second Computer Science year at University\n> of Murcia, Spain\n>\n> Location: Murcia, Spain (CET, UTC+1)\n>\n> Languages: C (solid), shell(bash) (good)\n>\n> Tools: git(proficient)\n>\n> I've checked that I'm eligible for GSoC 2026.\n>\n> Email: pabloosabaterr@gmail.com\n> GitHub: https://github.com/pabloosabaterr\n>\n> ## Availability\n>\n> My classes end the first week of May. From then until September I\n> won't have any classes which leaves me free to fully focus on the\n> project. I can dedicate 8+ hours each day, and for sure 40 hours a\n> week.\n>\n> ## Relevant Projects\n>\n> - 16 bit CPU emulator. Good example of C programming.\n>\n>   cpu: https://github.com/pabloosabaterr/CPU16\n>\n> - Compiler. Good example of working on bigger projects.\n>\n>   compiler: https://github.com/pabloosabaterr/Orn\n>\n> ## Pre-GSoC Work\n>\n> ### Introduction\n>\n> **[GSoC] Introduction Pablo Sabater**\n>\n> https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com\n>\n> **Description**: A mailing list thread where I introduced myself to\n> the git community.\n>\n> ### Microproject\n>\n> **[GSoC PATCH v4] t9200: replace test -f/-d with modern path helpers**\n>\n> https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n>\n> **Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n>\n> **Description**: Replaces `test -f` with helper `test_path_is_file`,\n> which makes debugging failing tests easier with better reporting.\n> As suggested as microproject.\n>\n> ### Other contributions\n>\n> **[GSoC PATCH v2] test-lib: print escape sequence names**\n>\n> https://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n>\n> **Status**: Will merge to `next`.\n>\n> **Description**: In failed expected/actual checks printing, the escape\n> sequences were shown as their octal code. This patch fixes that to\n> print the actual escape sequence name, adds tests, and updates the\n> expected output.\n>\n> **[GSoC PATCH] t9200: handle missing CVS with skip_all**\n>\n> https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n>\n> **Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n>\n> **Description**: wraps CVS setup in a skip_all for clearer failure\n> reporting and moves Git initialization into its own\n> test_expect_success.\n>\n> **Re: [PATCH] gc: add git maintenance list command**\n>\n> https://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/\n>\n> **Description**: code review for a patch sent.\n>\n> **[GSoC] Proposal: Complete and extend remote-object-info for git cat-file**\n>\n> https://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/\n>\n> **Description**: Proposal draft thread.\n>\n> **[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to batch-command**\n>\n> https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n>\n> **Description**: While testing Eric's v11 I've found and reported a\n> new bug. On `remote-object-info` when it's preceded by a local query,\n> `data->type` isn't being cleared. Causing it to return the wrong type.\n>\n> I have also studied the documentation provided and Eric Ju's work from\n> v0 to v11 including all the feedback he got up to March 2025, the\n> feedback he got from Junio Hamano and Jeff King, taking notes about\n> what's left to be done and what else I can contribute to the already\n> proposed project. That's how I've identified everything that I will\n> address on the Problem, Solution and Timeline sections.\n>\n> I built Eric Ju's v11 and tested the bugs reported to his patch [5],\n> I've confirmed the segfault and the `die()`, and found a new one:\n> - When a local `info` runs before `remote-object-info` sharing the\n> same format string, `data->type` isn't being cleared. A blob queried\n> remotely after a local commit, `data->type` for blob becomes 'commit'\n> with no error. I reported it on the mailing list [6].\n>\n> I attempted to test rebasing Eric Ju's v11 to master and got conflicts\n> on 4 out of the 8 commits:\n> - `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n>         - `t/t1006-cat-file.sh`\n> - `d918f720d8` fetch-pack: refactor packet writing.\n>         - `fetch-pack.c`\n> - `2daf9ed803` transport: add client support for object-info.\n>         - `Makefile`\n> - `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n>         - `object-file.c`, `object-store-ll.h` (deleted).\n>\n> I'm being active on the mailing list and learning the Git flow of work\n> and from the feedback I've received from the maintainers (Junio) from\n> my patches.\n>\n> Following the project guidelines, I haven't done anything on the\n> project that could step on other candidates' work before being\n> accepted, and instead I'm focusing on understanding the project and\n> its needs, and independent patches that will make the Git project more\n> familiar and understandable to me.\n>\n> ## The Problem\n>\n> Eric Ju's work remains unmerged after v11 because of these issues:\n>\n>  - The format validation uses `strstr()` which only checks for\n> `%(objectsize)`. This causes two different errors:\n>    - Atoms that `expand_atom()` recognizes but the remote doesn't\n> (`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when\n> accessing `data->type` it only contains garbage, causing segfault, as\n> Jeff King noted [3].\n>    - Unknown atoms by `expand_atom()`, returns 0, calling\n> `strbuf_expand_bad_format` on `expand_format()`, which calls `die()`,\n> as Jeff King found [3].\n>    Both cases block the command, including local `info` queries if the\n> same format string is shared. Unsupported remote placeholders should\n> return an empty string, matching how `for-each-ref` returns empty for\n> known, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n>\n>  - When local and remote queries are mixed, `data->type` is not being\n> cleared between commands. `remote-object-info` returns the wrong type\n> data from a previous local query [6].\n>\n>  - Style and code issues marked by Junio Hamano [2] and Jeff King [3]\n> [5] are still undone.\n>    - comment style.\n>    - `#define` formatting.\n>    - line length.\n>    - misleading error messages.\n>    - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n>    - if/else invert at `get_remote_info()`.\n>  - `%(objecttype)` is not yet supported on either client or server side.\n>\n> ## The Solution\n>\n> There are two main goals:\n>\n> ### Goal 1: Rebase and finish Eric's work\n>\n> Starting from where Eric Ju left off, I will rebase it on top of the\n> current `master` branch and address the feedback left to do:\n> - Fix style in comments, `#define` formatting and line length.\n> - Fix misleading error message in the overflow check.\n> - Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n> - Invert if/else on `get_remote_info()` to keep the small block first\n> (the error one) as Junio suggested.\n>\n> #### Replace `strstr()` format validation with allow_list in `expand_atom()`\n>\n> `strstr()` isn't enough to fully validate the placeholders, it only\n> searches for `%(objectsize)` and unsupported placeholders cause\n> segfaults. Jeff King noted [4] that the fix was to refactor the\n> validation with an allow_list in `expand_atom()` or `expand_format()`.\n> The best option is to place the validation at `expand_atom()`, but why\n> `expand_atom()` ?\n> - There are two cases, first, inside `expand_atom()` before returning\n> (segfault) and second, calls `die()` when `expand_atom()` returns 0.\n>   Placing the `allow_list` at the top of `expand_atom()` prevents both\n> errors, on remote mode, append nothing to `sb` and return 1, accessing\n> `data->type` won't cause segfault and prevents `expand_format()` from\n> reaching `die()`.\n>   As extra safety, initializing `data->type` to `OBJ_BAD` and check\n> for `NULL` from `type_name()` makes it that even without `allow_list`,\n> uninitialized data doesn't cause a segfault.\n>   At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the\n> allow_list. Goal 2 will bring `%(objecttype)` support.\n>\n> ### Goal 2: Adding `%(objecttype)`\n>\n> Following what Calvin Wan did in 2021 [8] for `%(objectsize)`, v2\n> protocol needs to be extended on the server side to support the new\n> `%(objecttype)` placeholder:\n> - extend `object_info_advertise()` at `serve.c`\n> - add .type to `requested_info` struct at `serve.c`\n> - support `type` in `cap_object_info()` at `protocol-caps.c`\n> - look for type at `send_info()` at `protocol-caps.c`\n>\n> Following object-info protocol docs [7] it should look like:\n> ```\n>   attrs = \"size\" SP \"type\"\n>   obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n>   obj-info = obj-id SP obj-size SP obj-type\n>   info = PKT-LINE(attrs LF)\n>         *PKT-LINE(obj-info LF)\n> ```\n>\n> `%(objecttype)` needs to be added to the `allow_list`. Client side\n> needs to learn to ask for `%(objecttype)` from remote, parse what has\n> been received and fill `expand_data` with the actual type. This makes\n> it return the object type instead of the empty string returned while\n> it was unsupported.\n>\n> Default format evolves to `%(objectname) %(objecttype) %(objectsize)`.\n> Test and document new placeholder support and server side extension.\n>\n> #### Backward Compatibility\n>\n> There are four possible scenarios to happen between client and server:\n>\n> 1. **The server doesn't know type (new client but old server)**:\n>\n>    After receiving the server capabilities, a client will only request\n> what the server advertises. The `allow_list` would handle this,\n> returning an empty string when the server doesn't support it.\n>\n> 2. **The server knows type but the client doesn't (new server but old client)**:\n>\n>    Following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\n> keys\", it will ignore type, and request only the known capabilities.\n>\n> 3. **Both know type (new client and new server)**:\n>\n>    Server advertises type, client requests it and gets the type data.\n>\n> 4. **Both know type but protocol middleware doesn't (new client, new\n> server but old middleware)**:\n>\n>    If a server advertises type but client doesn't receive type, a\n> client won't ask for anything unadvertised, if a client asks for type\n> but the server doesn't receive it, it will only return the known\n> capabilities.\n>\n> **performance considerations**\n>\n> To get an object type, we have to look only at the header, to get the\n> size `oid_object_info()` at `object-file.c` is being called which\n> already returns the object type in the same call. Sending the string\n> with the type will only be, worst case scenario 6 bytes for the\n> \"commit\" string.\n>\n> ## Timeline\n>\n> I've designed this to work with enough time so final work can be\n> shorter than what's said here\n>\n> May 1-24: Community Bonding\n> - Keep working on my ongoing patches and new ones.\n> - Talk and meet with mentor that I'm assigned with, to get feedback\n> about my proposal, how I will report my progress apart from the code\n> submitted and possible blogs, and tips and tricks to work better at\n> Git.\n> - Confirm with mentor that the `allow_list` approach is still the best option.\n> - Draft commits structure.\n> - Setup a blog to keep track about how GSoC at Git is going.\n>\n> Week 1-2: (May 26 - June 8)\n> - Start Goal 1 fixes.\n> - Fix style and code issues.\n>\n> Week 3-4: (June 9 - June 22)\n> - Start with Goal 1 implementations (allow_list approach).\n>\n> Week 5-6: (June 23 - July 6):\n> - Goal 1 should be polished or close to the final form.\n> - Send patch series for Goal 1.\n> - Start Goal 2.\n> - Prepare the midterm report.\n>\n> **Midterm evaluation** (July 7 - 11) as specified on GSoC timeline docs\n> - Goal 1 submitted.\n>\n> Week 7-8: (July 14 - July 27)\n> - Start with server side v2 protocol extension (`%(objecttype)`).\n>\n> Week 9-10: (July 28 - August 10)\n> - Add `%(objecttype)` to the `allow_list` from Goal 1.\n> - Client side extension.\n> - End to end tests and documentation.\n> - Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n> - Send patch series.\n>\n> Week 11-12: (August 11 - August 24)\n> - Goal 2 should be close to be done.\n> - Polish everything, all tests pass, good test coverage, no\n> style/comment issues.\n> - Final documentation review.\n> - Prepare for final evaluation.\n>\n> **Final evaluation** (August 18-24) as specified on GSoC timeline docs\n>\n> ### Additional objectives\n>\n> If there is enough time, or for future work after the project. I've\n> some ideas on how this could evolve:\n>\n> #### More placeholders support\n>\n> I've checked that Eric's v11 patch only supports `%(objectsize)` on\n> server side, but on the client side there are other placeholders that\n> can be added too. With the `allow_list` and having Goal 2 implemented,\n> adding more placeholders becomes trivial.\n>\n> - `%(objectsize:disk)`: Returns the size on the disk (compressed or as\n> a delta) instead of returning the uncompressed size that\n> `%(objectsize)` does. To do this, the server would need to send what's\n> the actual size on disk data.\n>\n> - `%(deltabase)`: Returns the delta base object OID. non delta objects\n> return zero OID as it does on local.\n>\n> #### Returning missing blobs from a tree ordered\n>\n> In a partial clone, someone might want to know what blobs are missing\n> inside a concrete tree and their size before fetching them.\n> The idea is to build on top of `remote-object-info`:\n> Given a tree hash, return the missing blobs (inside that tree) ordered by size.\n>\n> Thanks for reading my proposal and considering my application. I'm\n> very excited about this opportunity,\n> Pablo\n>\n> [1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n> \"Eric Ju's v11 patch\"\n>\n> [2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\n> Hamano feedback\"\n>\n> [3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n> \"Jeff King feedback\"\n>\n> [4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n> \"options for strstr() by Jeff King\"\n>\n> [5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n> \"Jeff King follow-up\"\n>\n> [6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n> \"data->type not being cleared bug\"\n>\n> [7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n> \"object-info protocol docs\"\n>\n> [8]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n> \"Calvin Wan's patch series\"\n>\n> ---\n>\n> Again, thanks a lot for the feedback.\n"},{"id":"539098","messageId":"CAP8UFD2PDqrpV-Y8EntJxfaRDP7aBXr47nQcVPeX=80yiLAoHw@mail.gmail.com","threadId":"65227","inReplyTo":"CAN5EUNQdNtPq1mEBUXOjRJ_t2n=cSUS9dz+HUfqbFjrjZVoGLQ@mail.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-16T11:21:23Z","receivedAt":"2026-03-16T11:21:35Z","isPatch":false,"body":"Hi Pablo,\n\nOn Sat, Mar 14, 2026 at 7:31 PM Pablo <pabloosabaterr@gmail.com> wrote:\n\n> #### Backward Compatibility\n>\n> There are four possible scenarios to happen between client and server:\n>\n> 1. **The server doesn't know type (new client but old server)**:\n>\n>    After receiving the server capabilities, a client will only request\n> what the server advertises. The `allow_list` would handle this,\n> returning an empty string when the server doesn't support it.\n\nThis is not very clear and maybe answering the following questions\ncould help clarify:\n\n1) What is returning an empty string. Is it the `allow_list`, the\nclient, the server or something else?\n2) And what is actually reported to the user (en error, a warning, nothing)?\n3) Also is it what is implemented in Eric's v11, or what you suggest\nimplementing?\n\n> 2. **The server knows type but the client doesn't (new server but old client)**:\n>\n>    Following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\n> keys\", it will ignore type, and request only the known capabilities.\n\nQuestions 2) and 3) above might be relevant here too.\n\n> 3. **Both know type (new client and new server)**:\n>\n>    Server advertises type, client requests it and gets the type data.\n>\n> 4. **Both know type but protocol middleware doesn't (new client, new\n> server but old middleware)**:\n>\n>    If a server advertises type but client doesn't receive type, a\n> client won't ask for anything unadvertised, if a client asks for type\n> but the server doesn't receive it, it will only return the known\n> capabilities.\n\nQuestions 2) and 3) above might be relevant here too.\n\n[...]\n\n> Thanks for reading my proposal and considering my application. I'm\n> very excited about this opportunity,\n\nThanks for your proposal.\n\nBest.\n"},{"id":"539127","messageId":"20260316160558.143619-1-pabloosabaterr@gmail.com","threadId":"65227","inReplyTo":"CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com","subject":"[GSoC v3] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Pablo Sabater","fromEmail":"pabloosabaterr@gmail.com","sentAt":"2026-03-16T16:05:08Z","receivedAt":"2026-03-16T16:06:03Z","isPatch":false,"body":"Thanks for the feedback on v2, Christian and Chandra. \n\nChanges from v2:\n\n> 1) What is returning an empty string. Is it the `allow_list`, the\n> client, the server or something else?\n> 2) And what is actually reported to the user (en error, a warning, nothing)?\n> 3) Also is it what is implemented in Eric's v11, or what you suggest\n> implementing?\n\n- Backward Compatibility expanded to answer the questions from Christian at the v2 feedback.\n- Performance Considerations now uses #### instead of bold ****.\n- Moved draft proposal on Pre-GSoC to its own subsection.\n- Added --graph-max RFC patch to Other Contributions.\n- Capitalization of subsections\n\n## Synopsis\n\nGit's partial clone allows cloning repositories without downloading all objects (blobs, trees, ...). These objects are fetched on demand from the remote when needed. However, when a user needs metadata about these remote objects (size, type, hash, ...), Git has no efficient way of doing this without downloading all the object content.\n\nThe server side support for `object-info` protocol was implemented by Calvin Wan in 2021 [8]. Eric Ju built the client-side `remote-object-info` for `cat-file --batch-command`.\n\nThis project finishes Eric Ju's work on `remote-object-info` for `git cat-file --batch-command` [1], resolves the pending feedback from Junio Hamano [2] and Jeff King [3] [4] [5], and extends support for `%(objecttype)`.\n\nExpected project size: 350 hours (Medium)\n\n## About Me and Contact\n\nName: Pablo Sabater Jiménez (he/him)\n\nAge: 19\n\nEducation: Currently on my second Computer Science year at University of Murcia, Spain\n\nLocation: Murcia, Spain (CET, UTC+1)\n\nLanguages: C (solid), shell(bash) (good)\n\nTools: git(proficient)\n\nI've checked that I'm eligible for GSoC 2026.\n\nEmail: pabloosabaterr@gmail.com\n\nGitHub: https://github.com/pabloosabaterr\n\n## Availability\n\nMy classes end the first week of May. From then until September I won't have any classes which leaves me free to fully focus on the project. I can dedicate 8+ hours each day, and for sure 40 hours a week.\n\n## Relevant Projects\n\n- 16 bit CPU emulator. Good example of C programming.\n \n  cpu: https://github.com/pabloosabaterr/CPU16\n\n- Compiler. Good example of working on bigger projects.\n \n  compiler: https://github.com/pabloosabaterr/Orn\n\n## Pre-GSoC Work\n\n### Introduction\n\n**[GSoC] Introduction Pablo Sabater**\n\nhttps://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com\n\n**Description**: A mailing list thread where I introduced myself to the git community.\n\n### Microproject\n\n**[GSoC PATCH v4] t9200: replace test -f/-d with modern path helpers**\n\nhttps://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n\n**Description**: Replaces `test -f` with helper `test_path_is_file`, which makes debugging failing tests easier with better reporting.\nAs suggested as microproject.\n\n### Draft Proposal\n\n**[GSoC] Proposal: Complete and extend remote-object-info for git cat-file**\n\nhttps://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/\n\n**Description**: Proposal draft thread.\n\n### Other Contributions\n\n**[GSoC PATCH v2] test-lib: print escape sequence names**\n\nhttps://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n\n**Status**: Will merge to `next`.\n\n**Description**: In failed expected/actual checks printing, the escape sequences were shown as their octal code. This patch fixes that to print the actual escape sequence name, adds tests, and updates the expected output.\n\n**[GSoC PATCH] t9200: handle missing CVS with skip_all**\n\nhttps://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n\n**Description**: Wraps CVS setup in a skip_all for clearer failure reporting and moves Git initialization into its own test_expect_success.\n\n**Re: [PATCH] gc: add git maintenance list command**\n\nhttps://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/\n\n**Description**: Code review for a patch sent.\n\n**[GSoC RFC PATCH] graph: add --graph-max option to limit displayed columns**\n\nhttps://lore.kernel.org/git/20260316133426.117684-1-pabloosabaterr@gmail.com/\n\n**Status**: RFC, waiting for feedback.\n\n**Description**: Adds `--graph-max` option to `git log --graph` to cap the number of columns that will be displayed. Helps readability for projects with many branches.\n\n**[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to batch-command**\n\nhttps://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\n**Description**: While testing Eric's v11 I've found and reported a new bug. On `remote-object-info` when it's preceded by a local query, `data->type` isn't being cleared. Causing it to return the wrong type.\n\nI have also studied the documentation provided and Eric Ju's work from v0 to v11 including all the feedback he got up to March 2025, the feedback he got from Junio Hamano and Jeff King, taking notes about what's left to be done and what else I can contribute to the already proposed project. That's how I've identified everything that I will address on the Problem, Solution and Timeline sections.\n\nI built Eric Ju's v11 and tested the bugs reported to his patch [5], I've confirmed the segfault and the `die()`, and found a new one:\n- When a local `info` runs before `remote-object-info` sharing the same format string, `data->type` isn't being cleared. A blob queried remotely after a local commit, `data->type` for blob becomes 'commit' with no error. I reported it on the mailing list [6].\n\nI attempted to test rebasing Eric Ju's v11 to master and got conflicts on 4 out of the 8 commits:\n- `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n        - `t/t1006-cat-file.sh`\n- `d918f720d8` fetch-pack: refactor packet writing.\n        - `fetch-pack.c`\n- `2daf9ed803` transport: add client support for object-info.\n        - `Makefile`\n- `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n        - `object-file.c`, `object-store-ll.h` (deleted).\n\nI'm being active on the mailing list and learning the Git flow of work and from the feedback I've received from the maintainers (Junio) from my patches.\n\nFollowing the project guidelines, I haven't done anything on the project that could step on other candidates' work before being accepted, and instead I'm focusing on understanding the project and its needs, and independent patches that will make the Git project more familiar and understandable to me.\n\n## The Problem\n\nEric Ju's work remains unmerged after v11 because of these issues:\n \n - The format validation uses `strstr()` which only checks for `%(objectsize)`. This causes two different errors:\n   - Atoms that `expand_atom()` recognizes but the remote doesn't (`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when accessing `data->type` it only contains garbage, causing segfault, as Jeff King noted [3].\n   - Unknown atoms by `expand_atom()`, returns 0, calling `strbuf_expand_bad_format` on `expand_format()`, which calls `die()`, as Jeff King found [3].\n   Both cases block the command, including local `info` queries if the same format string is shared. Unsupported remote placeholders should return an empty string, matching how `for-each-ref` returns empty for known, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n \n - When local and remote queries are mixed, `data->type` is not being cleared between commands. `remote-object-info` returns the wrong type data from a previous local query [6].\n \n - Style and code issues marked by Junio Hamano [2] and Jeff King [3] [5] are still undone.\n   - comment style.\n   - `#define` formatting.\n   - line length.\n   - misleading error messages.\n   - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n   - if/else invert at `get_remote_info()`.\n - `%(objecttype)` is not yet supported on either client or server side.\n\n## The Solution\n\nThere are two main goals:\n\n### Goal 1: Rebase and finish Eric's work\n\nStarting from where Eric Ju left off, I will rebase it on top of the current `master` branch and address the feedback left to do:\n- Fix style in comments, `#define` formatting and line length.\n- Fix misleading error message in the overflow check.\n- Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n- Invert if/else on `get_remote_info()` to keep the small block first (the error one) as Junio suggested.\n\n#### Replace `strstr()` format validation with allow_list in `expand_atom()`\n\n`strstr()` isn't enough to fully validate the placeholders, it only searches for `%(objectsize)` and unsupported placeholders cause segfaults. Jeff King noted [4] that the fix was to refactor the validation with an allow_list in `expand_atom()` or `expand_format()`. The best option is to place the validation at `expand_atom()`, but why `expand_atom()` ?\n- There are two cases, first, inside `expand_atom()` before returning (segfault) and second, calls `die()` when `expand_atom()` returns 0.\n  Placing the `allow_list` at the top of `expand_atom()` prevents both errors, on remote mode, append nothing to `sb` and return 1, accessing `data->type` won't cause segfault and prevents `expand_format()` from reaching `die()`.\n  As extra safety, initializing `data->type` to `OBJ_BAD` and check for `NULL` from `type_name()` makes it that even without `allow_list`, uninitialized data doesn't cause a segfault.\n  At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the allow_list. Goal 2 will bring `%(objecttype)` support.\n\n### Goal 2: Adding `%(objecttype)`\n\nFollowing what Calvin Wan did in 2021 [8] for `%(objectsize)`, v2 protocol needs to be extended on the server side to support the new `%(objecttype)` placeholder:\n- extend `object_info_advertise()` at `serve.c`\n- add .type to `requested_info` struct at `serve.c`\n- support `type` in `cap_object_info()` at `protocol-caps.c`\n- look for type at `send_info()` at `protocol-caps.c`\n\nFollowing object-info protocol docs [7] it should look like:\n```\n  attrs = \"size\" SP \"type\"\n  obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n  obj-info = obj-id SP obj-size SP obj-type\n  info = PKT-LINE(attrs LF)\n        *PKT-LINE(obj-info LF)\n```\n\n`%(objecttype)` needs to be added to the `allow_list`. Client side needs to learn to ask for `%(objecttype)` from remote, parse what has been received and fill `expand_data` with the actual type. This makes it return the object type instead of the empty string returned while it was unsupported.\n\nDefault format evolves to `%(objectname) %(objecttype) %(objectsize)`. Test and document new placeholder support and server side extension.\n\n#### Backward Compatibility\n\nThere are four possible scenarios to happen between client and server:\n\n1. **The server doesn't know type (new client but old server)**:\n\n   After receiving the server capabilities, the client doesn't see `type` being advertised. When the user format string has `%(objecttype)`, `expand_atom()` checks the `allow_list`, finds that type was not fetched. Appends an empty string to the output buffer and returns 1. The user will see an empty field where `type` should be, no errors nor warnings. In Eric Ju's v11, this would crash, as described in The Problem section, the `allow_list` from Goal 1 is what fixes this, following `for-each-ref` behaviour for known but inapplicable atoms as Jeff King suggested [4] [5].\n\n2. **The server knows type but the client doesn't (new server but old client)**:\n\n   The server advertises `type`, but the client doesn't know `type` and following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown keys\", it silently ignores the `type` and only asks for the known (`size`). The server returns only what was requested, user will see the output for `size` but not for `type`. This doesn't need any new code, the v2 protocol already behaves like this.\n\n3. **Both know type (new client and new server)**:\n\n   The server advertises `type`, the client requests `type` and receives the type data. `expand_atom()` finds `type` in the `allow_list`, fills `data->type` and then the user will see the object type in the output. This is Goal 2.\n\n4. **Both know type but protocol middleware doesn't (new client, new server but old middleware)**:\n\n   This becomes case 1 or 2 depending on what side is being affected by the middleware. If the middleware removes `type` from the server advertised capabilities, the client never sees it and treats the server as it was old server, it becomes case 1 (empty string). If the middleware removes `type` from the client request, the server will only see `size` being requested and only returns size data, it becomes case 2.\n   \n#### Performance Considerations\n\nTo get an object type, we have to look only at the header, to get the size `oid_object_info()` at `object-file.c` is being called which already returns the object type in the same call. Sending the string with the type will only be, worst case scenario 6 bytes for the \"commit\" string.\n\n## Timeline\n\nI've designed this to work with enough time so final work can be shorter than what's said here\n\nMay 1-24: Community Bonding\n- Keep working on my ongoing patches and new ones.\n- Talk and meet with mentor that I'm assigned with, to get feedback about my proposal, how I will report my progress apart from the code submitted and possible blogs, and tips and tricks to work better at Git.\n- Confirm with mentor that the `allow_list` approach is still the best option.\n- Draft commits structure.\n- Setup a blog to keep track about how GSoC at Git is going.\n\nWeek 1-2: (May 26 - June 8)\n- Start Goal 1 fixes.\n- Fix style and code issues.\n\nWeek 3-4: (June 9 - June 22)\n- Start with Goal 1 implementations (allow_list approach).\n\nWeek 5-6: (June 23 - July 6):\n- Goal 1 should be polished or close to the final form.\n- Send patch series for Goal 1.\n- Start Goal 2.\n- Prepare the midterm report.\n\n**Midterm evaluation** (July 7 - 11) as specified on GSoC timeline docs\n- Goal 1 submitted.\n\nWeek 7-8: (July 14 - July 27)\n- Start with server side v2 protocol extension (`%(objecttype)`).\n\nWeek 9-10: (July 28 - August 10)\n- Add `%(objecttype)` to the `allow_list` from Goal 1.\n- Client side extension.\n- End to end tests and documentation.\n- Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n- Send patch series.\n\nWeek 11-12: (August 11 - August 24)\n- Goal 2 should be close to be done.\n- Polish everything, all tests pass, good test coverage, no style/comment issues.\n- Final documentation review.\n- Prepare for final evaluation.\n\n**Final evaluation** (August 18-24) as specified on GSoC timeline docs\n\n### Additional objectives\n\nIf there is enough time, or for future work after the project. I've some ideas on how this could evolve:\n\n#### More placeholders support\n\nI've checked that Eric's v11 patch only supports `%(objectsize)` on server side, but on the client side there are other placeholders that can be added too. With the `allow_list` and having Goal 2 implemented, adding more placeholders becomes trivial.\n\n- `%(objectsize:disk)`: Returns the size on the disk (compressed or as a delta) instead of returning the uncompressed size that `%(objectsize)` does. To do this, the server would need to send what's the actual size on disk data.\n\n- `%(deltabase)`: Returns the delta base object OID. non delta objects return zero OID as it does on local.\n\n#### Returning missing blobs from a tree ordered\n\nIn a partial clone, someone might want to know what blobs are missing inside a concrete tree and their size before fetching them.\nThe idea is to build on top of `remote-object-info`:\nGiven a tree hash, return the missing blobs (inside that tree) ordered by size.\n\nThanks for reading my proposal and considering my application. I'm very excited about this opportunity,\nPablo\n \n[1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/ \"Eric Ju's v11 patch\"\n\n[2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio Hamano feedback\"\n\n[3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/ \"Jeff King feedback\"\n\n[4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/ \"options for strstr() by Jeff King\"\n\n[5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/ \"Jeff King follow-up\"\n\n[6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/ \"data->type not being cleared bug\"\n\n[7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info \"object-info protocol docs\"\n\n[8]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t \"Calvin Wan's patch series\"\n"},{"id":"539164","messageId":"CAOLa=ZREJsZ_p9Hfi_+XePW8c1n7xd-UjEuMSh=AHrQC8X75Tw@mail.gmail.com","threadId":"65227","inReplyTo":"CAN5EUNQdNtPq1mEBUXOjRJ_t2n=cSUS9dz+HUfqbFjrjZVoGLQ@mail.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-16T21:38:14Z","receivedAt":"2026-03-16T21:38:16Z","isPatch":false,"body":"Pablo <pabloosabaterr@gmail.com> writes:\n\n> Hi Chandra, thanks a lot for the feedback! :)\n>\n>> You should upload your proposal on the GSoC website and add the link to it here.\n>> The proposal can be then updated later as many times as you like.\n>\n> GSoC proposals opens March 16th, for now I'll send my v2 here and as\n> soon as I can I'll swap to GSoC website and send the link to the\n> thread.\n>\n> To avoid having you reread everything again this is what I've done from v1:\n>\n>   Moved context explanation from The Problem to Synopsis and\n> Availability below About Me and Contact.\n>   Split Pre-GSoC patches into status (for code patches) and\n> description to improve readability.\n>   Added a code review and proposal thread to the Pre-GSoC section.\n>   Added new lines where noted and fixed capitalization.\n>   Correctly credited Jeff King for the allow_list idea and added new\n> [8] for Calvin Wan's work.\n>   Community bonding now includes continuing patches and setting up a blog.\n>   Removed most of the duplicated iteration on the Timeline from The\n> Problem. (feels a bit empty now tho).\n>\n\nPerhaps a diff would be a good addition for next time? :)\n\n> I paste here my v2 with the requested changes:\n>\n> ## Synopsis\n>\n> Git's partial clone allows cloning repositories without downloading\n> all objects (blobs, trees, ...). These objects are fetched on demand\n> from the remote when needed. However, when a user needs metadata about\n> these remote objects (size, type, hash, ...), Git has no efficient way\n> of doing this without downloading all the object content.\n>\n> The server side support for `object-info` protocol was implemented by\n> Calvin Wan in 2021 [8]. Eric Ju built the client-side\n> `remote-object-info` for `cat-file --batch-command`.\n>\n> This project finishes Eric Ju's work on `remote-object-info` for `git\n> cat-file --batch-command` [1], resolves the pending feedback from\n> Junio Hamano [2] and Jeff King [3] [4] [5], and extends support for\n> `%(objecttype)`.\n>\n\nNice to see that you've linked in the relevant resources.\n\n> Expected project size: 350 hours (Medium)\n>\n> ## About Me and Contact\n>\n> Name: Pablo Sabater Jiménez (he/him)\n>\n> Age: 19\n>\n> Education: Currently on my second Computer Science year at University\n> of Murcia, Spain\n>\n> Location: Murcia, Spain (CET, UTC+1)\n>\n> Languages: C (solid), shell(bash) (good)\n>\n> Tools: git(proficient)\n>\n> I've checked that I'm eligible for GSoC 2026.\n>\n> Email: pabloosabaterr@gmail.com\n> GitHub: https://github.com/pabloosabaterr\n>\n> ## Availability\n>\n> My classes end the first week of May. From then until September I\n> won't have any classes which leaves me free to fully focus on the\n> project. I can dedicate 8+ hours each day, and for sure 40 hours a\n> week.\n>\n> ## Relevant Projects\n>\n> - 16 bit CPU emulator. Good example of C programming.\n>\n>   cpu: https://github.com/pabloosabaterr/CPU16\n>\n> - Compiler. Good example of working on bigger projects.\n>\n>   compiler: https://github.com/pabloosabaterr/Orn\n>\n> ## Pre-GSoC Work\n>\n> ### Introduction\n>\n> **[GSoC] Introduction Pablo Sabater**\n>\n> https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com\n>\n> **Description**: A mailing list thread where I introduced myself to\n> the git community.\n>\n> ### Microproject\n>\n> **[GSoC PATCH v4] t9200: replace test -f/-d with modern path helpers**\n>\n> https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n>\n> **Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n>\n> **Description**: Replaces `test -f` with helper `test_path_is_file`,\n> which makes debugging failing tests easier with better reporting.\n> As suggested as microproject.\n>\n> ### Other contributions\n>\n> **[GSoC PATCH v2] test-lib: print escape sequence names**\n>\n> https://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n>\n> **Status**: Will merge to `next`.\n>\n> **Description**: In failed expected/actual checks printing, the escape\n> sequences were shown as their octal code. This patch fixes that to\n> print the actual escape sequence name, adds tests, and updates the\n> expected output.\n>\n> **[GSoC PATCH] t9200: handle missing CVS with skip_all**\n>\n> https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n>\n> **Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n>\n> **Description**: wraps CVS setup in a skip_all for clearer failure\n> reporting and moves Git initialization into its own\n> test_expect_success.\n>\n> **Re: [PATCH] gc: add git maintenance list command**\n>\n> https://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/\n>\n> **Description**: code review for a patch sent.\n>\n> **[GSoC] Proposal: Complete and extend remote-object-info for git cat-file**\n>\n> https://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/\n>\n> **Description**: Proposal draft thread.\n>\n> **[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to batch-command**\n>\n> https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n>\n> **Description**: While testing Eric's v11 I've found and reported a\n> new bug. On `remote-object-info` when it's preceded by a local query,\n> `data->type` isn't being cleared. Causing it to return the wrong type.\n>\n\nNice to see that you're proactive and already testing out the branch.\n\n> I have also studied the documentation provided and Eric Ju's work from\n> v0 to v11 including all the feedback he got up to March 2025, the\n> feedback he got from Junio Hamano and Jeff King, taking notes about\n> what's left to be done and what else I can contribute to the already\n> proposed project. That's how I've identified everything that I will\n> address on the Problem, Solution and Timeline sections.\n>\n> I built Eric Ju's v11 and tested the bugs reported to his patch [5],\n> I've confirmed the segfault and the `die()`, and found a new one:\n> - When a local `info` runs before `remote-object-info` sharing the\n> same format string, `data->type` isn't being cleared. A blob queried\n> remotely after a local commit, `data->type` for blob becomes 'commit'\n> with no error. I reported it on the mailing list [6].\n>\n> I attempted to test rebasing Eric Ju's v11 to master and got conflicts\n> on 4 out of the 8 commits:\n> - `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n>         - `t/t1006-cat-file.sh`\n> - `d918f720d8` fetch-pack: refactor packet writing.\n>         - `fetch-pack.c`\n> - `2daf9ed803` transport: add client support for object-info.\n>         - `Makefile`\n> - `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n>         - `object-file.c`, `object-store-ll.h` (deleted).\n\nIt's been a while, so this is expected. I guess the first week[s] would\nmostly be getting this series up-to date.\n\n>\n> I'm being active on the mailing list and learning the Git flow of work\n> and from the feedback I've received from the maintainers (Junio) from\n> my patches.\n>\n> Following the project guidelines, I haven't done anything on the\n> project that could step on other candidates' work before being\n> accepted, and instead I'm focusing on understanding the project and\n> its needs, and independent patches that will make the Git project more\n> familiar and understandable to me.\n\nI know this is the silent expectation, but nice to see it listed out.\n\n>\n> ## The Problem\n>\n> Eric Ju's work remains unmerged after v11 because of these issues:\n>\n>  - The format validation uses `strstr()` which only checks for\n> `%(objectsize)`. This causes two different errors:\n>    - Atoms that `expand_atom()` recognizes but the remote doesn't\n> (`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when\n> accessing `data->type` it only contains garbage, causing segfault, as\n> Jeff King noted [3].\n>    - Unknown atoms by `expand_atom()`, returns 0, calling\n> `strbuf_expand_bad_format` on `expand_format()`, which calls `die()`,\n> as Jeff King found [3].\n>    Both cases block the command, including local `info` queries if the\n> same format string is shared. Unsupported remote placeholders should\n> return an empty string, matching how `for-each-ref` returns empty for\n> known, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n>\n>  - When local and remote queries are mixed, `data->type` is not being\n> cleared between commands. `remote-object-info` returns the wrong type\n> data from a previous local query [6].\n>\n>  - Style and code issues marked by Junio Hamano [2] and Jeff King [3]\n> [5] are still undone.\n>    - comment style.\n>    - `#define` formatting.\n>    - line length.\n>    - misleading error messages.\n>    - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n>    - if/else invert at `get_remote_info()`.\n>  - `%(objecttype)` is not yet supported on either client or server side.\n>\n\nAgain, well done on the research. It is always nice to see the\nrequirements being listed out clearly which makes the objective clearer.\n\n> ## The Solution\n>\n> There are two main goals:\n>\n> ### Goal 1: Rebase and finish Eric's work\n>\n> Starting from where Eric Ju left off, I will rebase it on top of the\n> current `master` branch and address the feedback left to do:\n> - Fix style in comments, `#define` formatting and line length.\n> - Fix misleading error message in the overflow check.\n> - Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n> - Invert if/else on `get_remote_info()` to keep the small block first\n> (the error one) as Junio suggested.\n>\n> #### Replace `strstr()` format validation with allow_list in `expand_atom()`\n>\n> `strstr()` isn't enough to fully validate the placeholders, it only\n> searches for `%(objectsize)` and unsupported placeholders cause\n> segfaults. Jeff King noted [4] that the fix was to refactor the\n> validation with an allow_list in `expand_atom()` or `expand_format()`.\n> The best option is to place the validation at `expand_atom()`, but why\n> `expand_atom()` ?\n> - There are two cases, first, inside `expand_atom()` before returning\n> (segfault) and second, calls `die()` when `expand_atom()` returns 0.\n>   Placing the `allow_list` at the top of `expand_atom()` prevents both\n> errors, on remote mode, append nothing to `sb` and return 1, accessing\n> `data->type` won't cause segfault and prevents `expand_format()` from\n> reaching `die()`.\n>   As extra safety, initializing `data->type` to `OBJ_BAD` and check\n> for `NULL` from `type_name()` makes it that even without `allow_list`,\n> uninitialized data doesn't cause a segfault.\n>   At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the\n> allow_list. Goal 2 will bring `%(objecttype)` support.\n>\n> ### Goal 2: Adding `%(objecttype)`\n>\n> Following what Calvin Wan did in 2021 [8] for `%(objectsize)`, v2\n> protocol needs to be extended on the server side to support the new\n> `%(objecttype)` placeholder:\n> - extend `object_info_advertise()` at `serve.c`\n> - add .type to `requested_info` struct at `serve.c`\n> - support `type` in `cap_object_info()` at `protocol-caps.c`\n> - look for type at `send_info()` at `protocol-caps.c`\n>\n> Following object-info protocol docs [7] it should look like:\n> ```\n>   attrs = \"size\" SP \"type\"\n>   obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n>   obj-info = obj-id SP obj-size SP obj-type\n>   info = PKT-LINE(attrs LF)\n>         *PKT-LINE(obj-info LF)\n> ```\n>\n> `%(objecttype)` needs to be added to the `allow_list`. Client side\n> needs to learn to ask for `%(objecttype)` from remote, parse what has\n> been received and fill `expand_data` with the actual type. This makes\n> it return the object type instead of the empty string returned while\n> it was unsupported.\n>\n> Default format evolves to `%(objectname) %(objecttype) %(objectsize)`.\n> Test and document new placeholder support and server side extension.\n>\n> #### Backward Compatibility\n>\n> There are four possible scenarios to happen between client and server:\n>\n> 1. **The server doesn't know type (new client but old server)**:\n>\n>    After receiving the server capabilities, a client will only request\n> what the server advertises. The `allow_list` would handle this,\n> returning an empty string when the server doesn't support it.\n>\n> 2. **The server knows type but the client doesn't (new server but old client)**:\n>\n>    Following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\n> keys\", it will ignore type, and request only the known capabilities.\n>\n> 3. **Both know type (new client and new server)**:\n>\n>    Server advertises type, client requests it and gets the type data.\n>\n> 4. **Both know type but protocol middleware doesn't (new client, new\n> server but old middleware)**:\n>\n>    If a server advertises type but client doesn't receive type, a\n> client won't ask for anything unadvertised, if a client asks for type\n> but the server doesn't receive it, it will only return the known\n> capabilities.\n>\n> **performance considerations**\n>\n> To get an object type, we have to look only at the header, to get the\n> size `oid_object_info()` at `object-file.c` is being called which\n> already returns the object type in the same call. Sending the string\n> with the type will only be, worst case scenario 6 bytes for the\n> \"commit\" string.\n>\n> ## Timeline\n>\n> I've designed this to work with enough time so final work can be\n> shorter than what's said here\n>\n> May 1-24: Community Bonding\n> - Keep working on my ongoing patches and new ones.\n> - Talk and meet with mentor that I'm assigned with, to get feedback\n> about my proposal, how I will report my progress apart from the code\n> submitted and possible blogs, and tips and tricks to work better at\n> Git.\n> - Confirm with mentor that the `allow_list` approach is still the best option.\n> - Draft commits structure.\n> - Setup a blog to keep track about how GSoC at Git is going.\n>\n> Week 1-2: (May 26 - June 8)\n> - Start Goal 1 fixes.\n> - Fix style and code issues.\n>\n> Week 3-4: (June 9 - June 22)\n> - Start with Goal 1 implementations (allow_list approach).\n>\n> Week 5-6: (June 23 - July 6):\n> - Goal 1 should be polished or close to the final form.\n> - Send patch series for Goal 1.\n> - Start Goal 2.\n> - Prepare the midterm report.\n>\n> **Midterm evaluation** (July 7 - 11) as specified on GSoC timeline docs\n> - Goal 1 submitted.\n>\n> Week 7-8: (July 14 - July 27)\n> - Start with server side v2 protocol extension (`%(objecttype)`).\n>\n> Week 9-10: (July 28 - August 10)\n> - Add `%(objecttype)` to the `allow_list` from Goal 1.\n> - Client side extension.\n> - End to end tests and documentation.\n> - Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n> - Send patch series.\n>\n> Week 11-12: (August 11 - August 24)\n> - Goal 2 should be close to be done.\n> - Polish everything, all tests pass, good test coverage, no\n> style/comment issues.\n> - Final documentation review.\n> - Prepare for final evaluation.\n>\n> **Final evaluation** (August 18-24) as specified on GSoC timeline docs\n>\n> ### Additional objectives\n>\n> If there is enough time, or for future work after the project. I've\n> some ideas on how this could evolve:\n>\n> #### More placeholders support\n>\n> I've checked that Eric's v11 patch only supports `%(objectsize)` on\n> server side, but on the client side there are other placeholders that\n> can be added too. With the `allow_list` and having Goal 2 implemented,\n> adding more placeholders becomes trivial.\n>\n> - `%(objectsize:disk)`: Returns the size on the disk (compressed or as\n> a delta) instead of returning the uncompressed size that\n> `%(objectsize)` does. To do this, the server would need to send what's\n> the actual size on disk data.\n>\n> - `%(deltabase)`: Returns the delta base object OID. non delta objects\n> return zero OID as it does on local.\n>\n> #### Returning missing blobs from a tree ordered\n>\n> In a partial clone, someone might want to know what blobs are missing\n> inside a concrete tree and their size before fetching them.\n> The idea is to build on top of `remote-object-info`:\n> Given a tree hash, return the missing blobs (inside that tree) ordered by size.\n>\n\nYou might want to look 'git-backfill(1)', I recall there was some\nthoughts on extending that command to do something similar. But I don't\nremember on the top of my head.\n\n> Thanks for reading my proposal and considering my application. I'm\n> very excited about this opportunity,\n> Pablo\n>\n> [1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n> \"Eric Ju's v11 patch\"\n>\n> [2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\n> Hamano feedback\"\n>\n> [3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n> \"Jeff King feedback\"\n>\n> [4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n> \"options for strstr() by Jeff King\"\n>\n> [5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n> \"Jeff King follow-up\"\n>\n> [6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n> \"data->type not being cleared bug\"\n>\n> [7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n> \"object-info protocol docs\"\n>\n> [8]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n> \"Calvin Wan's patch series\"\n>\n> ---\n>\n> Again, thanks a lot for the feedback.\n\nRegards,\nKarthik\n"},{"id":"539283","messageId":"CAN5EUNQtFY=TpwddqGOSHva7RmunWGLzfHU+4c=OvdqipA1ptA@mail.gmail.com","threadId":"65227","inReplyTo":"CAOLa=ZREJsZ_p9Hfi_+XePW8c1n7xd-UjEuMSh=AHrQC8X75Tw@mail.gmail.com","subject":"Re: [GSoC] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Pablo","fromEmail":"pabloosabaterr@gmail.com","sentAt":"2026-03-18T10:45:12Z","receivedAt":"2026-03-18T10:45:28Z","isPatch":false,"body":"Karthik Nayak (<karthik.188@gmail.com>) writes:\n\n> Perhaps a diff would be a good addition for next time? :)\n\nYes, I'll add a diff from now on.\n\n> It's been a while, so this is expected. I guess the first week[s] would\n> mostly be getting this series up-to date.\n\nYes, it's mentioned in The Solution section, but I'll make it more clear\nadding it explicitly to the Timeline that it will be the first thing to do.\n\n> You might want to look 'git-backfill(1)', I recall there was some\n> thoughts on extending that command to do something similar. But I don't\n> remember on the top of my head.\n\nThanks, I didn't know about that, from what I've found the 'git-backfill'\nextension that Stolee is working on [1], it's similar but (correct me\nif i'm wrong)\n'git-backfill' fetches the branch/path. This idea would only bring the\nmetadata asked on a\nformat string e.g.:\"%(objectname) %(objectsize) %(objecttype)\" leveraging\non what has been done on Goal 1 and Goal 2. I'll add a clarification on the\nproposal about this.\n\nThis would get along with 'git-backfill' extension by, querying the metadata\nfrom a branch first and then fetching it with 'git-backfill'\n\nThanks for the feedback and compliments,\nPablo\n\n[1]: https://lore.kernel.org/git/pull.2070.git.1773707361.gitgitgadget@gmail.com/\n\"Stolee 'git-backfill' extension\"\n"},{"id":"539284","messageId":"CAN5EUNQWvL7McJg833+pcZOmGyxegPewMpC4472-=V41-uaoJQ@mail.gmail.com","threadId":"65227","inReplyTo":"20260316160558.143619-1-pabloosabaterr@gmail.com","subject":"Re: [GSoC v4] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Pablo","fromEmail":"pabloosabaterr@gmail.com","sentAt":"2026-03-18T11:42:33Z","receivedAt":"2026-03-18T11:42:49Z","isPatch":false,"body":"I've realised that I've sent v3 in reply to v1 instead of v2, here and on some\nof the patches. I'm very sorry about that, I'll do it correctly from now on.\n\nThis v4 addresses v3 improvements and karthik feedback on v2\n\nchanges from v3: (detailed diff below the proposal):\n- Patch status updated\n- Timeline shows explicitly to rebase on week1\n- Extra objective return missing blobs updated to be more clear\n- fixed format for pdf creation\n\nGSoC doesn't let me share the pdf sent. so I can't share a link.\nI'm sending this as markdown because it is preferred plain text\nbut to see the actual pdf that will be delivered, it can be done with:\n\n  pandoc <file> -f markdown+autolink_bare_uris -o proposal.pdf -V\ngeometry:\"margin=2cm\" -V colorlinks=true -V urlcolor=blue --toc\n--number-sections\n\n# Synopsis\n\nGit's partial clone allows cloning repositories without downloading\nall objects (blobs, trees, ...). These objects are fetched on demand\nfrom the remote when needed. However, when a user needs metadata about\nthese remote objects (size, type, hash, ...), Git has no efficient way\nof doing this without downloading all the object content.\n\nThe server side support for `object-info` protocol was implemented by\nCalvin Wan in 2021 [8]. Eric Ju built the client-side\n`remote-object-info` for `cat-file --batch-command`.\n\nThis project finishes Eric Ju's work on `remote-object-info` for `git\ncat-file --batch-command` [1], resolves the pending feedback from\nJunio Hamano [2] and Jeff King [3] [4] [5], and extends support for\n`%(objecttype)`.\n\nExpected project size: 350 hours (Medium)\n\n# About Me and Contact\n\nName: Pablo Sabater Jiménez (he/him)\n\nAge: 19\n\nEducation: Currently on my second Computer Science year at University\nof Murcia, Spain\n\nLocation: Murcia, Spain (CET, UTC+1)\n\nLanguages: C (solid), shell(bash) (good)\n\nTools: git(proficient)\n\nI've checked that I'm eligible for GSoC 2026.\n\nEmail: pabloosabaterr@gmail.com\n\nGitHub: https://github.com/pabloosabaterr\n\n# Availability\n\nMy classes end the first week of May. From then until September I\nwon't have any classes which leaves me free to fully focus on the\nproject. I can dedicate 8+ hours each day, and for sure 40 hours a\nweek.\n\n# Relevant Projects\n\n- 16 bit CPU emulator. Good example of C programming.\n\n  cpu: https://github.com/pabloosabaterr/CPU16\n\n- Compiler. Good example of working on bigger projects.\n\n  compiler: https://github.com/pabloosabaterr/Orn\n\n# Pre-GSoC Work\n\n## Introduction\n\n[[GSoC] Introduction Pablo\nSabater](https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com)\n\n**Description**: A mailing list thread where I introduced myself to\nthe git community.\n\n## Microproject\n\n[[GSoC PATCH v4] t9200: replace test -f/-d with modern path\nhelpers](https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/)\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`. Will merge\nto `master`.\n\n**Description**: Replaces `test -f` with helper `test_path_is_file`,\nwhich makes debugging failing tests easier with better reporting.\nAs suggested as microproject.\n\n## Draft Proposal\n\n[[GSoC] Proposal: Complete and extend remote-object-info for git\ncat-file](https://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/)\n\n**Description**: Proposal draft thread.\n\n## Other Contributions\n\n[[GSoC PATCH v2] test-lib: print escape sequence\nnames](https://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/)\n\n**Status**: Will merge to `next`.\n\n**Description**: In failed expected/actual checks printing, the escape\nsequences were shown as their octal code. This patch fixes that to\nprint the actual escape sequence name, adds tests, and updates the\nexpected output.\n\n[[GSoC PATCH] t9200: handle missing CVS with\nskip_all](https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/)\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`. Will merge\nto `master`.\n\n**Description**: Wraps CVS setup in a skip_all for clearer failure\nreporting and moves Git initialization into its own\ntest_expect_success.\n\n[Re: [PATCH] gc: add git maintenance list\ncommand](https://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/)\n\n**Description**: Code review for a patch sent.\n\n[[GSoC RFC PATCH] graph: add --graph-max option to limit displayed\ncolumns](https://lore.kernel.org/git/20260316133426.117684-1-pabloosabaterr@gmail.com/)\n\n**Status**: RFC, waiting for feedback.\n\n**Description**: Adds `--graph-max` option to `git log --graph` to cap\nthe number of columns that will be displayed. Helps readability for\nprojects with many branches.\n\n[[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to\nbatch-command](https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/)\n\n**Description**: While testing Eric's v11 I've found and reported a\nnew bug. On `remote-object-info` when it's preceded by a local query,\n`data->type` isn't being cleared. Causing it to return the wrong type.\n\nI have also studied the documentation provided and Eric Ju's work from\nv0 to v11 including all the feedback he got up to March 2025, the\nfeedback he got from Junio Hamano and Jeff King, taking notes about\nwhat's left to be done and what else I can contribute to the already\nproposed project. That's how I've identified everything that I will\naddress on the Problem, Solution and Timeline sections.\n\nI built Eric Ju's v11 and tested the bugs reported to his patch [5],\nI've confirmed the segfault and the `die()`, and found a new one:\n\n- When a local `info` runs before `remote-object-info` sharing the\nsame format string, `data->type` isn't being cleared. A blob queried\nremotely after a local commit, `data->type` for blob becomes 'commit'\nwith no error. I reported it on the mailing list [6].\n\nI attempted to test rebasing Eric Ju's v11 to master and got conflicts\non 4 out of the 8 commits:\n\n- `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n        - `t/t1006-cat-file.sh`\n- `d918f720d8` fetch-pack: refactor packet writing.\n        - `fetch-pack.c`\n- `2daf9ed803` transport: add client support for object-info.\n        - `Makefile`\n- `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n        - `object-file.c`, `object-store-ll.h` (deleted).\n\nI'm being active on the mailing list and learning the Git flow of work\nand from the feedback I've received from the maintainers (Junio) from\nmy patches.\n\nFollowing the project guidelines, I haven't done anything on the\nproject that could step on other candidates' work before being\naccepted, and instead I'm focusing on understanding the project and\nits needs, and independent patches that will make the Git project more\nfamiliar and understandable to me.\n\n# The Problem\n\nEric Ju's work remains unmerged after v11 because of these issues:\n\n - The format validation uses `strstr()` which only checks for\n`%(objectsize)`. This causes two different errors:\n   - Atoms that `expand_atom()` recognizes but the remote doesn't\n(`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when\naccessing `data->type` it only contains garbage, causing segfault, as\nJeff King noted [3].\n   - Unknown atoms by `expand_atom()`, returns 0, calling\n`strbuf_expand_bad_format` on `expand_format()`, which calls `die()`,\nas Jeff King found [3].\n   Both cases block the command, including local `info` queries if the\nsame format string is shared. Unsupported remote placeholders should\nreturn an empty string, matching how `for-each-ref` returns empty for\nknown, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n\n - When local and remote queries are mixed, `data->type` is not being\ncleared between commands. `remote-object-info` returns the wrong type\ndata from a previous local query [6].\n\n - Style and code issues marked by Junio Hamano [2] and Jeff King [3]\n[5] are still undone.\n\n   - comment style.\n   - `#define` formatting.\n   - line length.\n   - misleading error messages.\n   - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n   - if/else invert at `get_remote_info()`.\n - `%(objecttype)` is not yet supported on either client or server side.\n\n# The Solution\n\nThere are two main goals:\n\n## Goal 1: Rebase and finish Eric's work\n\nStarting from where Eric Ju left off, I will rebase it on top of the\ncurrent `master` branch and address the feedback left to do:\n\n- Fix style in comments, `#define` formatting and line length.\n- Fix misleading error message in the overflow check.\n- Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n- Invert if/else on `get_remote_info()` to keep the small block first\n(the error one) as Junio suggested.\n\n#### Replace `strstr()` format validation with allow_list in `expand_atom()`\n\n`strstr()` isn't enough to fully validate the placeholders, it only\nsearches for `%(objectsize)` and unsupported placeholders cause\nsegfaults. Jeff King noted [4] that the fix was to refactor the\nvalidation with an allow_list in `expand_atom()` or `expand_format()`.\nThe best option is to place the validation at `expand_atom()`, but why\n`expand_atom()` ?\n\n- There are two cases, first, inside `expand_atom()` before returning\n(segfault) and second, calls `die()` when `expand_atom()` returns 0.\n  Placing the `allow_list` at the top of `expand_atom()` prevents both\nerrors, on remote mode, append nothing to `sb` and return 1, accessing\n`data->type` won't cause segfault and prevents `expand_format()` from\nreaching `die()`.\n  As extra safety, initializing `data->type` to `OBJ_BAD` and check\nfor `NULL` from `type_name()` makes it that even without `allow_list`,\nuninitialized data doesn't cause a segfault.\n  At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the\nallow_list. Goal 2 will bring `%(objecttype)` support.\n\n## Goal 2: Adding `%(objecttype)`\n\nFollowing what Calvin Wan did in 2021 [8] for `%(objectsize)`, v2\nprotocol needs to be extended on the server side to support the new\n`%(objecttype)` placeholder:\n\n- extend `object_info_advertise()` at `serve.c`\n- add .type to `requested_info` struct at `serve.c`\n- support `type` in `cap_object_info()` at `protocol-caps.c`\n- look for type at `send_info()` at `protocol-caps.c`\n\nFollowing object-info protocol docs [7] it should look like:\n```\n  attrs = \"size\" SP \"type\"\n  obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n  obj-info = obj-id SP obj-size SP obj-type\n  info = PKT-LINE(attrs LF)\n        *PKT-LINE(obj-info LF)\n```\n\n`%(objecttype)` needs to be added to the `allow_list`. Client side\nneeds to learn to ask for `%(objecttype)` from remote, parse what has\nbeen received and fill `expand_data` with the actual type. This makes\nit return the object type instead of the empty string returned while\nit was unsupported.\n\nDefault format evolves to `%(objectname) %(objecttype) %(objectsize)`.\nTest and document new placeholder support and server side extension.\n\n## Backward Compatibility\n\nThere are four possible scenarios to happen between client and server:\n\n1. **The server doesn't know type (new client but old server)**:\n\n   After receiving the server capabilities, the client doesn't see\n`type` being advertised. When the user format string has\n`%(objecttype)`, `expand_atom()` checks the `allow_list`, finds that\ntype was not fetched. Appends an empty string to the output buffer and\nreturns 1. The user will see an empty field where `type` should be, no\nerrors nor warnings. In Eric Ju's v11, this would crash, as described\nin The Problem section, the `allow_list` from Goal 1 is what fixes\nthis, following `for-each-ref` behaviour for known but inapplicable\natoms as Jeff King suggested [4] [5].\n\n2. **The server knows type but the client doesn't (new server but old client)**:\n\n   The server advertises `type`, but the client doesn't know `type`\nand following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\nkeys\", it silently ignores the `type` and only asks for the known\n(`size`). The server returns only what was requested, user will see\nthe output for `size` but not for `type`. This doesn't need any new\ncode, the v2 protocol already behaves like this.\n\n3. **Both know type (new client and new server)**:\n\n   The server advertises `type`, the client requests `type` and\nreceives the type data. `expand_atom()` finds `type` in the\n`allow_list`, fills `data->type` and then the user will see the object\ntype in the output. This is Goal 2.\n\n4. **Both know type but protocol middleware doesn't (new client, new\nserver but old middleware)**:\n\n   This becomes case 1 or 2 depending on what side is being affected\nby the middleware. If the middleware removes `type` from the server\nadvertised capabilities, the client never sees it and treats the\nserver as it was old server, it becomes case 1 (empty string). If the\nmiddleware removes `type` from the client request, the server will\nonly see `size` being requested and only returns size data, it becomes\ncase 2.\n\n## Performance Considerations\n\nTo get an object type, we have to look only at the header, to get the\nsize `oid_object_info()` at `object-file.c` is being called which\nalready returns the object type in the same call. Sending the string\nwith the type will only be, worst case scenario 6 bytes for the\n\"commit\" string.\n\n# Timeline\n\nI've designed this to work with enough time so final work can be\nshorter than what's said here\n\nMay 1-24: Community Bonding\n\n- Keep working on my ongoing patches and new ones.\n- Talk and meet with mentor that I'm assigned with, to get feedback\nabout my proposal, how I will report my progress apart from the code\nsubmitted and possible blogs, and tips and tricks to work better at\nGit.\n- Confirm with mentor that the `allow_list` approach is still the best option.\n- Draft commits structure.\n- Setup a blog to keep track about how GSoC at Git is going.\n\nWeek 1-2: (May 26 - June 8)\n\n- First of all will be rebasing Eric Ju's v11.\n- Start Goal 1 fixes.\n- Fix style and code issues.\n\nWeek 3-4: (June 9 - June 22)\n\n- Start with Goal 1 implementations (allow_list approach).\n\nWeek 5-6: (June 23 - July 6):\n\n- Goal 1 should be polished or close to the final form.\n- Send patch series for Goal 1.\n- Start Goal 2.\n- Prepare the midterm report.\n\n**Midterm evaluation** (July 7 - 11) as specified on GSoC timeline docs\n\n- Goal 1 submitted.\n\nWeek 7-8: (July 14 - July 27)\n\n- Start with server side v2 protocol extension (`%(objecttype)`).\n\nWeek 9-10: (July 28 - August 10)\n\n- Add `%(objecttype)` to the `allow_list` from Goal 1.\n- Client side extension.\n- End to end tests and documentation.\n- Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n- Send patch series.\n\nWeek 11-12: (August 11 - August 24)\n\n- Goal 2 should be close to be done.\n- Polish everything, all tests pass, good test coverage, no\nstyle/comment issues.\n- Final documentation review.\n- Prepare for final evaluation.\n\n**Final evaluation** (August 18-24) as specified on GSoC timeline docs\n\n## Additional objectives\n\nIf there is enough time, or for future work after the project. I've\nsome ideas on how this could evolve:\n\n## More placeholders support\n\nI've checked that Eric's v11 patch only supports `%(objectsize)` on\nserver side, but on the client side there are other placeholders that\ncan be added too. With the `allow_list` and having Goal 2 implemented,\nadding more placeholders becomes trivial.\n\n- `%(objectsize:disk)`: Returns the size on the disk (compressed or as\na delta) instead of returning the uncompressed size that\n`%(objectsize)` does. To do this, the server would need to send what's\nthe actual size on disk data.\n\n- `%(deltabase)`: Returns the delta base object OID. non delta objects\nreturn zero OID as it does on local.\n\n## Returning missing blobs from a tree ordered\n\nIn a partial clone, someone might want to know what blobs are missing\ninside a concrete tree and order them before fetching them.\nThe idea is to build on top of `remote-object-info` and what's been\nbuilt in Goal 1 and Goal 2:\nGiven a tree hash, return the missing blobs (inside that tree) ordered\nby an orderable atom (size, name, type, ...).\n\nThis looks similar to Stolee's work on `git-backfill` [9], the key\ndifference is that `git-backfill` fetches the missing objects from a\npath/object, while this would only query the metadata of the missing\nblobs without fetching them and ordered by a given atom.\n\nThanks for reading my proposal and considering my application. I'm\nvery excited about this opportunity,\n\nPablo\n\n\\[1\\]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\"Eric Ju's v11 patch\"\n\n\\[2\\]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\nHamano feedback\"\n\n\\[3\\]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n\"Jeff King feedback\"\n\n\\[4\\]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n\"options for strstr() by Jeff King\"\n\n\\[5\\]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n\"Jeff King follow-up\"\n\n\\[6\\]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\"data->type not being cleared bug\"\n\n\\[7\\]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n\"object-info protocol docs\"\n\n\\[8\\]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n\"Calvin Wan's patch series\"\n\n\\[9\\]: https://lore.kernel.org/git/pull.2070.git.1773707361.gitgitgadget@gmail.com/\n\"git-backfill extension from Stolee\"\n\n[1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\"Eric Ju's v11 patch\"\n\n[2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\nHamano feedback\"\n\n[3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n\"Jeff King feedback\"\n\n[4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n\"options for strstr() by Jeff King\"\n\n[5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n\"Jeff King follow-up\"\n\n[6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\"data->type not being cleared bug\"\n\n[7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n\"object-info protocol docs\"\n\n[8]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n\"Calvin Wan's patch series\"\n\n[9]: https://lore.kernel.org/git/pull.2070.git.1773707361.gitgitgadget@gmail.com/\n\"git-backfill extension from Stolee\"\n---\ndiff --git a/v3.md b/v4.md\nindex 60c86de..c5b8bc6 100755\n--- a/v3prop.md\n+++ b/proposal-pdfFormat.md\n@@ -1 +1 @@\n-## Synopsis\n+# Synopsis\n@@ -11 +11 @@ Expected project size: 350 hours (Medium)\n-## About Me and Contact\n+# About Me and Contact\n@@ -31 +31 @@ GitHub: https://github.com/pabloosabaterr\n-## Availability\n+# Availability\n@@ -35 +35 @@ My classes end the first week of May. From then until\nSeptember I won't have any\n-## Relevant Projects\n+# Relevant Projects\n@@ -45 +45 @@ My classes end the first week of May. From then until\nSeptember I won't have any\n-## Pre-GSoC Work\n+# Pre-GSoC Work\n@@ -47 +47 @@ My classes end the first week of May. From then until\nSeptember I won't have any\n-### Introduction\n+## Introduction\n@@ -49,3 +49 @@ My classes end the first week of May. From then until\nSeptember I won't have any\n-**[GSoC] Introduction Pablo Sabater**\n-\n-https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com\n+[[GSoC] Introduction Pablo\nSabater](https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com)\n@@ -55,3 +53 @@\nhttps://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@\n-### Microproject\n-\n-**[GSoC PATCH v4] t9200: replace test -f/-d with modern path helpers**\n+## Microproject\n@@ -59 +55 @@ https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@\n-https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n+[[GSoC PATCH v4] t9200: replace test -f/-d with modern path\nhelpers](https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/)\n@@ -61 +57 @@ https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/\n-**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n+**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`. Will\nmerge to `master`.\n@@ -66,3 +62 @@ As suggested as microproject.\n-### Draft Proposal\n-\n-**[GSoC] Proposal: Complete and extend remote-object-info for git cat-file**\n+## Draft Proposal\n@@ -70 +64 @@ As suggested as microproject.\n-https://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/\n+[[GSoC] Proposal: Complete and extend remote-object-info for git\ncat-file](https://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/)\n@@ -74 +68 @@ https://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@\n-### Other Contributions\n+## Other Contributions\n@@ -76,3 +70 @@\nhttps://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@\n-**[GSoC PATCH v2] test-lib: print escape sequence names**\n-\n-https://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n+[[GSoC PATCH v2] test-lib: print escape sequence\nnames](https://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/)\n@@ -84,3 +76 @@\nhttps://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/\n-**[GSoC PATCH] t9200: handle missing CVS with skip_all**\n-\n-https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n+[[GSoC PATCH] t9200: handle missing CVS with\nskip_all](https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/)\n@@ -88 +78 @@ https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n-**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`.\n+**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`. Will\nmerge to `master`.\n@@ -92,3 +82 @@\nhttps://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/\n-**Re: [PATCH] gc: add git maintenance list command**\n-\n-https://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/\n+[Re: [PATCH] gc: add git maintenance list\ncommand](https://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/)\n@@ -98,3 +86 @@\nhttps://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/\n-**[GSoC RFC PATCH] graph: add --graph-max option to limit displayed columns**\n-\n-https://lore.kernel.org/git/20260316133426.117684-1-pabloosabaterr@gmail.com/\n+[[GSoC RFC PATCH] graph: add --graph-max option to limit displayed\ncolumns](https://lore.kernel.org/git/20260316133426.117684-1-pabloosabaterr@gmail.com/)\n@@ -106,3 +92 @@\nhttps://lore.kernel.org/git/20260316133426.117684-1-pabloosabaterr@gmail.com/\n-**[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to\nbatch-command**\n-\n-https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n+[[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to\nbatch-command](https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/)\n@@ -114,0 +99 @@ I built Eric Ju's v11 and tested the bugs reported to\nhis patch [5], I've confir\n+\n@@ -117,0 +103 @@ I attempted to test rebasing Eric Ju's v11 to master\nand got conflicts on 4 out\n+\n@@ -131 +117 @@ Following the project guidelines, I haven't done\nanything on the project that co\n-## The Problem\n+# The Problem\n@@ -142,0 +129 @@ Eric Ju's work remains unmerged after v11 because of\nthese issues:\n+\n@@ -151 +138 @@ Eric Ju's work remains unmerged after v11 because of\nthese issues:\n-## The Solution\n+# The Solution\n@@ -155 +142 @@ There are two main goals:\n-### Goal 1: Rebase and finish Eric's work\n+## Goal 1: Rebase and finish Eric's work\n@@ -157,0 +145 @@ Starting from where Eric Ju left off, I will rebase\nit on top of the current `ma\n+\n@@ -165,0 +154 @@ Starting from where Eric Ju left off, I will rebase\nit on top of the current `ma\n+\n@@ -171 +160 @@ Starting from where Eric Ju left off, I will rebase it\non top of the current `ma\n-### Goal 2: Adding `%(objecttype)`\n+## Goal 2: Adding `%(objecttype)`\n@@ -173,0 +163 @@ Following what Calvin Wan did in 2021 [8] for\n`%(objectsize)`, v2 protocol needs\n+\n@@ -192 +182 @@ Default format evolves to `%(objectname) %(objecttype)\n%(objectsize)`. Test and\n-#### Backward Compatibility\n+## Backward Compatibility\n@@ -212 +202 @@ There are four possible scenarios to happen between\nclient and server:\n-#### Performance Considerations\n+## Performance Considerations\n@@ -216 +206 @@ To get an object type, we have to look only at the\nheader, to get the size `oid_\n-## Timeline\n+# Timeline\n@@ -220,0 +211 @@ May 1-24: Community Bonding\n+\n@@ -227,0 +219,2 @@ Week 1-2: (May 26 - June 8)\n+\n+- First of all will be rebasing Eric Ju's v11.\n@@ -231,0 +225 @@ Week 3-4: (June 9 - June 22)\n+\n@@ -234,0 +229 @@ Week 5-6: (June 23 - July 6):\n+\n@@ -240,0 +236 @@ Week 5-6: (June 23 - July 6):\n+\n@@ -243,0 +240 @@ Week 7-8: (July 14 - July 27)\n+\n@@ -246,0 +244 @@ Week 9-10: (July 28 - August 10)\n+\n@@ -253,0 +252 @@ Week 11-12: (August 11 - August 24)\n+\n@@ -261 +260 @@ Week 11-12: (August 11 - August 24)\n-### Additional objectives\n+## Additional objectives\n@@ -265 +264 @@ If there is enough time, or for future work after the\nproject. I've some ideas o\n-#### More placeholders support\n+## More placeholders support\n@@ -273 +272 @@ I've checked that Eric's v11 patch only supports\n`%(objectsize)` on server side,\n-#### Returning missing blobs from a tree ordered\n+## Returning missing blobs from a tree ordered\n@@ -275,3 +274,5 @@ I've checked that Eric's v11 patch only supports\n`%(objectsize)` on server side,\n-In a partial clone, someone might want to know what blobs are missing\ninside a concrete tree and their size before fetching them.\n-The idea is to build on top of `remote-object-info`:\n-Given a tree hash, return the missing blobs (inside that tree) ordered by size.\n+In a partial clone, someone might want to know what blobs are missing\ninside a concrete tree and order them before fetching them.\n+The idea is to build on top of `remote-object-info` and what's been\nbuilt in Goal 1 and Goal 2:\n+Given a tree hash, return the missing blobs (inside that tree)\nordered by an orderable atom (size, name, type, ...).\n+\n+This looks similar to Stolee's work on `git-backfill` [9], the key\ndifference is that `git-backfill` fetches the missing objects from a\npath/object, while this would only query the metadata of the missing\nblobs without fetching them and ordered by a given atom.\n@@ -279,0 +281 @@ Thanks for reading my proposal and considering my\napplication. I'm very excited\n+\n@@ -281,0 +284,18 @@ Pablo\n+\\[1\\]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\"Eric Ju's v11 patch\"\n+\n+\\[2\\]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\nHamano feedback\"\n+\n+\\[3\\]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n\"Jeff King feedback\"\n+\n+\\[4\\]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n\"options for strstr() by Jeff King\"\n+\n+\\[5\\]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n\"Jeff King follow-up\"\n+\n+\\[6\\]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\"data->type not being cleared bug\"\n+\n+\\[7\\]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n\"object-info protocol docs\"\n+\n+\\[8\\]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n\"Calvin Wan's patch series\"\n+\n+\\[9\\]: https://lore.kernel.org/git/pull.2070.git.1773707361.gitgitgadget@gmail.com/\n\"git-backfill extension from Stolee\"\n+\n@@ -296,0 +317,2 @@ Pablo\n+\n+[9]: https://lore.kernel.org/git/pull.2070.git.1773707361.gitgitgadget@gmail.com/\n\"git-backfill extension from Stolee\"\n\\ No newline at end of file\n"},{"id":"541442","messageId":"CAN5EUNRMoS0+Xa=D48r86XKftVn7rZxJUnmbOrOFvngXz7mvZg@mail.gmail.com","threadId":"65227","inReplyTo":"CAN5EUNQWvL7McJg833+pcZOmGyxegPewMpC4472-=V41-uaoJQ@mail.gmail.com","subject":"Re: [GSoC v4] Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Pablo","fromEmail":"pabloosabaterr@gmail.com","sentAt":"2026-04-12T14:41:05Z","receivedAt":"2026-04-12T14:41:24Z","isPatch":false,"body":"Hi,\nThis is the proposal version that matches with the final one sent.\nThere is no change to the actual proposal, it's mostly updated the\nwork done pre GSoC.\n\nThere's a diff below the actual proposal with the exact changes.\n\nYou can generate the pdf that has been sent with:\n\n  pandoc <file> -f markdown+autolink_bare_uris -o proposal.pdf -V\n  geometry:\"margin=2cm\" -V colorlinks=true -V urlcolor=blue --toc\n  --number-sections\n\nThanks,\nPablo.\n\n# Synopsis\n\nGit's partial clone allows cloning repositories without downloading\nall objects (blobs, trees, ...). These objects are fetched on demand\nfrom the remote when needed. However, when a user needs metadata about\nthese remote objects (size, type, hash, ...), Git has no efficient way\nof doing this without downloading all the object content.\n\nThe server side support for `object-info` protocol was implemented by\nCalvin Wan in 2021 [8]. Eric Ju built the client-side\n`remote-object-info` for `cat-file --batch-command`.\n\nThis project finishes Eric Ju's work on `remote-object-info` for `git\ncat-file --batch-command` [1], resolves the pending feedback from\nJunio Hamano [2] and Jeff King [3] [4] [5], and extends support for\n`%(objecttype)`.\n\nExpected project size: 350 hours (Medium)\n\n# About Me and Contact\n\nName: Pablo Sabater Jiménez (he/him)\n\nAge: 19\n\nEducation: Currently on my second Computer Science year at University\nof Murcia, Spain\n\nLocation: Murcia, Spain (CET, UTC+2)\n\nLanguages: C (solid), shell(bash) (good)\n\nTools: git(proficient)\n\nI've checked that I'm eligible for GSoC 2026.\n\nEmail: pabloosabaterr@gmail.com\n\nGitHub: https://github.com/pabloosabaterr\n\n# Availability\n\nMy classes end the first week of May. From then until September I\nwon't have any classes which leaves me free to fully focus on the\nproject. I can dedicate 8+ hours each day, and for sure 40 hours a\nweek.\n\n# Relevant Projects\n\n- 16 bit CPU emulator. Good example of C programming.\n\n  cpu: https://github.com/pabloosabaterr/CPU16\n\n- Compiler. Good example of working on bigger projects.\n\n  compiler: https://github.com/pabloosabaterr/Orn\n\n# Pre-GSoC Work\n\n## Introduction\n\n[[GSoC] Introduction Pablo\nSabater](https://lore.kernel.org/git/CAN5EUNR0KJ4VeuOF_bVupaTuGKGaeTKa0SMRAUoBPo5wWi8YGA@mail.gmail.com)\n\n**Description**: A mailing list thread where I introduced myself to\nthe git community.\n\n## Microproject\n\n[[GSoC PATCH v4] t9200: replace test -f/-d with modern path\nhelpers](https://lore.kernel.org/git/20260312173305.15112-1-pabloosabaterr@gmail.com/)\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`. Will merge\nto `master`.\n\n**Description**: Replaces `test -f` with helper `test_path_is_file`,\nwhich makes debugging failing tests easier with better reporting.\nAs suggested as microproject.\n\n## Draft Proposal\n\n[[GSoC] Proposal: Complete and extend remote-object-info for git\ncat-file](https://lore.kernel.org/git/CAN5EUNQKv-LCkbY+5scn6pk6fL8kpmjNR=66rjeY=NqKbqRkhA@mail.gmail.com/)\n\n**Description**: Proposal draft thread.\n\n## Other Contributions\n\n[[GSoC PATCH v2] test-lib: print escape sequence\nnames](https://lore.kernel.org/git/20260311031442.11942-1-pabloosabaterr@gmail.com/)\n\n**Status**: merged to `next` on 2026-03-13 at f545ea5a9c.\n\n**Description**: In failed expected/actual checks printing, the escape\nsequences were shown as their octal code. This patch fixes that to\nprint the actual escape sequence name, adds tests, and updates the\nexpected output.\n\n[[GSoC PATCH] t9200: handle missing CVS with\nskip_all](https://lore.kernel.org/git/20260311194002.190195-1-pabloosabaterr@gmail.com/)\n\n**Status**: Merged to `next` on 2026-03-12 at `8500bdf172`. Will merge\nto `master`.\n\n**Description**: Wraps CVS setup in a skip_all for clearer failure\nreporting and moves Git initialization into its own\ntest_expect_success.\n\n[[GSoC PATCH v6 0/3] graph: add --graph-lane-limit\noption](https://lore.kernel.org/git/20260328001113.1275291-1-pabloosabaterr@gmail.com/)\n\n**Status**: WIP.\n\n**Description**: Adds `--graph-lane-limit` option to `--graph` to\nlimit the number of horizontal lanes that will be shown. Helps\nreadability for projects with many branches.\n\n[[GSoC PATCH 0/3] receive-pack: fix HEAD check for\nupdateInstead](https://lore.kernel.org/git/20260330111822.165188-1-pabloosabaterr@gmail.com/)\n\n**Status**: pending review.\n\n**Description**: Fix updateInstead HEAD check that only looked for the\nbare repo context instead of the worktree HEAD, which rejected the\npushes even with the wt clean.\n\n## Code Reviews\n\n[Re: [PATCH] gc: add git maintenance list\ncommand](https://lore.kernel.org/git/20260313115932.15259-1-pabloosabaterr@gmail.com/)\n\n**Description**: Code review for a patch sent about simplifying a\nduplicated code.\n\n[Re: [PATCH] t2107: modernize path existence\ncheck](https://lore.kernel.org/all/CAN5EUNTNqC6+FPjKafoFfgaEzWdpXEV0QNwumF8CaxBEUOmA6Q@mail.gmail.com/)\n\n[Re: [GSoC][PATCH] t2000: modernize path checks to use helper\nfunctions](https://lore.kernel.org/all/CAN5EUNTSO7KvtO02c-EHJTK95rmcZKRBtKsn8kjNid1qupWZ0w@mail.gmail.com/)\n\n[Re: [PATCH] t5315: use test_path_is_file for loose-object\ncheck](https://lore.kernel.org/all/CAN5EUNR2mqpCMG0oPsDnzgZr-2yyL+S0A7p_MM62F7d4MjBuSA@mail.gmail.com/)\n\n**Description**: Reviews to newcomers on their microprojects patches.\n\n[[GSoC] Re: [PATCH v11 8/8] cat-file: add remote-object-info to\nbatch-command](https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/)\n\n**Description**: While testing Eric's v11 I've found and reported a\nnew bug. On `remote-object-info` when it's preceded by a local query,\n`data->type` isn't being cleared. Causing it to return the wrong type.\n\nI have also studied the documentation provided and Eric Ju's work from\nv0 to v11 including all the feedback he got up to March 2025, the\nfeedback he got from Junio Hamano and Jeff King, taking notes about\nwhat's left to be done and what else I can contribute to the already\nproposed project. That's how I've identified everything that I will\naddress on the Problem, Solution and Timeline sections.\n\nI built Eric Ju's v11 and tested the bugs reported to his patch [5],\nI've confirmed the segfault and the `die()`, and found a new one:\n\n- When a local `info` runs before `remote-object-info` sharing the\nsame format string, `data->type` isn't being cleared. A blob queried\nremotely after a local commit, `data->type` for blob becomes 'commit'\nwith no error. I reported it on the mailing list [6].\n\nI attempted to test rebasing Eric Ju's v11 to master and got conflicts\non 4 out of the 8 commits:\n\n- `d04cf85ece` t1006: split test utility functions into new \"lib-cat-file.sh\".\n        - `t/t1006-cat-file.sh`\n- `d918f720d8` fetch-pack: refactor packet writing.\n        - `fetch-pack.c`\n- `2daf9ed803` transport: add client support for object-info.\n        - `Makefile`\n- `c3ba4afaf6` cat-file: add remote-object-info to batch-command.\n        - `object-file.c`, `object-store-ll.h` (deleted).\n\nI'm being active on the mailing list, learning the Git flow of work\nand learning from the feedback I've received from the maintainers on\nmy patches and reviewing others.\n\nFollowing the project guidelines, I haven't done anything on the\nproject that could step on other candidates' work before being\naccepted, and instead I'm focusing on understanding the project and\nits needs, and independent patches that will make the Git project more\nfamiliar and understandable to me.\n\n# The Problem\n\nEric Ju's work remains unmerged after v11 because of these issues:\n\n - The format validation uses `strstr()` which only checks for\n`%(objectsize)`. This causes two different errors:\n   - Atoms that `expand_atom()` recognizes but the remote doesn't\n(`objecttype`,`deltabase`, ...), `expand_atom()` returns 1, but when\naccessing `data->type` it only contains garbage, causing segfault, as\nJeff King noted [3].\n   - Unknown atoms by `expand_atom()`, returns 0, calling\n`strbuf_expand_bad_format` on `expand_format()`, which calls `die()`,\nas Jeff King found [3].\n   Both cases block the command, including local `info` queries if the\nsame format string is shared. Unsupported remote placeholders should\nreturn an empty string, matching how `for-each-ref` returns empty for\nknown, but inapplicable atoms like `%(tagger)` on non-tags [4] [5].\n\n - When local and remote queries are mixed, `data->type` is not being\ncleared between commands. `remote-object-info` returns the wrong type\ndata from a previous local query [6].\n\n - Style and code issues marked by Junio Hamano [2] and Jeff King [3]\n[5] are still undone.\n\n   - comment style.\n   - `#define` formatting.\n   - line length.\n   - misleading error messages.\n   - missing `count > MAX_ALLOWED_OBJ_LIMIT` check at `split_cmdline().`\n   - if/else invert at `get_remote_info()`.\n - `%(objecttype)` is not yet supported on either client or server side.\n\n# The Solution\n\nThere are two main goals:\n\n## Goal 1: Rebase and finish Eric's work\n\nStarting from where Eric Ju left off, I will rebase it on top of the\ncurrent `master` branch and address the feedback left to do:\n\n- Fix style in comments, `#define` formatting and line length.\n- Fix misleading error message in the overflow check.\n- Add missing `count > MAX_ALLOWED_OBJ_LIMIT` check after `split_cmdline()`.\n- Invert if/else on `get_remote_info()` to keep the small block first\n(the error one) as Junio suggested.\n\n#### Replace `strstr()` format validation with allow_list in `expand_atom()`\n\n`strstr()` isn't enough to fully validate the placeholders, it only\nsearches for `%(objectsize)` and unsupported placeholders cause\nsegfaults. Jeff King noted [4] that the fix was to refactor the\nvalidation with an allow_list in `expand_atom()` or `expand_format()`.\nThe best option is to place the validation at `expand_atom()`, but why\n`expand_atom()` ?\n\n- There are two cases, first, inside `expand_atom()` before returning\n(segfault) and second, calls `die()` when `expand_atom()` returns 0.\n  Placing the `allow_list` at the top of `expand_atom()` prevents both\nerrors, on remote mode, append nothing to `sb` and return 1, accessing\n`data->type` won't cause segfault and prevents `expand_format()` from\nreaching `die()`.\n  As extra safety, initializing `data->type` to `OBJ_BAD` and check\nfor `NULL` from `type_name()` makes it that even without `allow_list`,\nuninitialized data doesn't cause a segfault.\n  At Goal 1, only `%(objectname)` and `%(objectsize)` will be in the\nallow_list. Goal 2 will bring `%(objecttype)` support.\n\n## Goal 2: Adding `%(objecttype)`\n\nFollowing what Calvin Wan did in 2021 [8] for `%(objectsize)`, v2\nprotocol needs to be extended on the server side to support the new\n`%(objecttype)` placeholder:\n\n- extend `object_info_advertise()` at `serve.c`\n- add .type to `requested_info` struct at `serve.c`\n- support `type` in `cap_object_info()` at `protocol-caps.c`\n- look for type at `send_info()` at `protocol-caps.c`\n\nFollowing object-info protocol docs [7] it should look like:\n```\n  attrs = \"size\" SP \"type\"\n  obj-type = \"blob\" | \"tree\" | \"commit\" | \"tag\"\n  obj-info = obj-id SP obj-size SP obj-type\n  info = PKT-LINE(attrs LF)\n        *PKT-LINE(obj-info LF)\n```\n\n`%(objecttype)` needs to be added to the `allow_list`. Client side\nneeds to learn to ask for `%(objecttype)` from remote, parse what has\nbeen received and fill `expand_data` with the actual type. This makes\nit return the object type instead of the empty string returned while\nit was unsupported.\n\nDefault format evolves to `%(objectname) %(objecttype) %(objectsize)`.\nTest and document new placeholder support and server side extension.\n\n## Backward Compatibility\n\nThere are four possible scenarios to happen between client and server:\n\n1. **The server doesn't know type (new client but old server)**:\n\n   After receiving the server capabilities, the client doesn't see\n`type` being advertised. When the user format string has\n`%(objecttype)`, `expand_atom()` checks the `allow_list`, finds that\ntype was not fetched. Appends an empty string to the output buffer and\nreturns 1. The user will see an empty field where `type` should be, no\nerrors nor warnings. In Eric Ju's v11, this would crash, as described\nin The Problem section, the `allow_list` from Goal 1 is what fixes\nthis, following `for-each-ref` behaviour for known but inapplicable\natoms as Jeff King suggested [4] [5].\n\n2. **The server knows type but the client doesn't (new server but old client)**:\n\n   The server advertises `type`, but the client doesn't know `type`\nand following `gitprotocol-v2.adoc`, \"Clients must ignore all unknown\nkeys\", it silently ignores the `type` and only asks for the known\n(`size`). The server returns only what was requested, user will see\nthe output for `size` but not for `type`. This doesn't need any new\ncode, the v2 protocol already behaves like this.\n\n3. **Both know type (new client and new server)**:\n\n   The server advertises `type`, the client requests `type` and\nreceives the type data. `expand_atom()` finds `type` in the\n`allow_list`, fills `data->type` and then the user will see the object\ntype in the output. This is Goal 2.\n\n4. **Both know type but protocol middleware doesn't (new client, new\nserver but old middleware)**:\n\n   This becomes case 1 or 2 depending on what side is being affected\nby the middleware. If the middleware removes `type` from the server\nadvertised capabilities, the client never sees it and treats the\nserver as it was old server, it becomes case 1 (empty string). If the\nmiddleware removes `type` from the client request, the server will\nonly see `size` being requested and only returns size data, it becomes\ncase 2.\n\n## Performance Considerations\n\nTo get an object type, we have to look only at the header, to get the\nsize `oid_object_info()` at `object-file.c` is being called which\nalready returns the object type in the same call. Sending the string\nwith the type will only be, worst case scenario 6 bytes for the\n\"commit\" string.\n\n# Timeline\n\nI've designed this to work with enough time so final work can be\nshorter than what's said here\n\nMay 1-24: Community Bonding\n\n- Keep working on my ongoing patches and new ones.\n- Talk and meet with mentor that I'm assigned with, to get feedback\nabout my proposal, how I will report my progress apart from the code\nsubmitted and possible blogs, and tips and tricks to work better at\nGit.\n- Confirm with mentor that the `allow_list` approach is still the best option.\n- Draft commits structure.\n- Setup a blog to keep track about how GSoC at Git is going.\n\nWeek 1-2: (May 26 - June 8)\n\n- First of all will be rebasing Eric Ju's v11.\n- Start Goal 1 fixes.\n- Fix style and code issues.\n\nWeek 3-4: (June 9 - June 22)\n\n- Start with Goal 1 implementations (allow_list approach).\n\nWeek 5-6: (June 23 - July 6):\n\n- Goal 1 should be polished or close to the final form.\n- Send patch series for Goal 1.\n- Start Goal 2.\n- Prepare the midterm report.\n\n**Midterm evaluation** (July 7 - 11) as specified on GSoC timeline docs\n\n- Goal 1 submitted.\n\nWeek 7-8: (July 14 - July 27)\n\n- Start with server side v2 protocol extension (`%(objecttype)`).\n\nWeek 9-10: (July 28 - August 10)\n\n- Add `%(objecttype)` to the `allow_list` from Goal 1.\n- Client side extension.\n- End to end tests and documentation.\n- Default format becomes `%(objectname) %(objecttype) %(objectsize)`.\n- Send patch series.\n\nWeek 11-12: (August 11 - August 24)\n\n- Goal 2 should be close to be done.\n- Polish everything, all tests pass, good test coverage, no\nstyle/comment issues.\n- Final documentation review.\n- Prepare for final evaluation.\n\n**Final evaluation** (August 18-24) as specified on GSoC timeline docs\n\n## Additional objectives\n\nIf there is enough time, or for future work after the project. I've\nsome ideas on how this could evolve:\n\n## More placeholders support\n\nI've checked that Eric's v11 patch only supports `%(objectsize)` on\nserver side, but on the client side there are other placeholders that\ncan be added too. With the `allow_list` and having Goal 2 implemented,\nadding more placeholders becomes trivial.\n\n- `%(objectsize:disk)`: Returns the size on the disk (compressed or as\na delta) instead of returning the uncompressed size that\n`%(objectsize)` does. To do this, the server would need to send what's\nthe actual size on disk data.\n\n- `%(deltabase)`: Returns the delta base object OID. non delta objects\nreturn zero OID as it does on local.\n\n## Returning missing blobs from a tree ordered\n\nIn a partial clone, someone might want to know what blobs are missing\ninside a concrete tree and order them before fetching them.\nThe idea is to build on top of `remote-object-info` and what's been\nbuilt in Goal 1 and Goal 2:\nGiven a tree hash, return the missing blobs (inside that tree) ordered\nby an orderable atom (size, name, type, ...).\n\nThis looks similar to Stolee's work on `git-backfill` [9], the key\ndifference is that `git-backfill` fetches the missing objects from a\npath/object, while this would only query the metadata of the missing\nblobs without fetching them and ordered by a given atom.\n\nThanks for reading my proposal and considering my application. I'm\nvery excited about this opportunity,\n\nPablo\n\n\\[1\\]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\"Eric Ju's v11 patch\"\n\n\\[2\\]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\nHamano feedback\"\n\n\\[3\\]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n\"Jeff King feedback\"\n\n\\[4\\]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n\"options for strstr() by Jeff King\"\n\n\\[5\\]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n\"Jeff King follow-up\"\n\n\\[6\\]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\"data->type not being cleared bug\"\n\n\\[7\\]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n\"object-info protocol docs\"\n\n\\[8\\]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n\"Calvin Wan's patch series\"\n\n\\[9\\]: https://lore.kernel.org/git/pull.2070.git.1773707361.gitgitgadget@gmail.com/\n\"git-backfill extension from Stolee\"\n\n[1]: https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\"Eric Ju's v11 patch\"\n\n[2]: https://lore.kernel.org/git/xmqqo6yr3wc4.fsf@gitster.g/ \"Junio\nHamano feedback\"\n\n[3]: https://lore.kernel.org/git/20250224234720.GC729825@coredump.intra.peff.net/\n\"Jeff King feedback\"\n\n[4]: https://lore.kernel.org/git/20250313060250.GH94015@coredump.intra.peff.net/\n\"options for strstr() by Jeff King\"\n\n[5]: https://lore.kernel.org/git/20250324033922.GB690093@coredump.intra.peff.net/\n\"Jeff King follow-up\"\n\n[6]: https://lore.kernel.org/git/20260312214154.89120-1-pabloosabaterr@gmail.com/\n\"data->type not being cleared bug\"\n\n[7]: https://github.com/git/git/blob/master/Documentation/gitprotocol-v2.adoc#object-info\n\"object-info protocol docs\"\n\n[8]: https://lore.kernel.org/git/20220728230210.2952731-1-calvinwan@google.com/#t\n\"Calvin Wan's patch series\"\n\n[9]: https://lore.kernel.org/git/pull.2070.git.1773707361.gitgitgadget@gmail.com/\n\"git-backfill extension from Stolee\"\n\ndiff --git a/v4.md b/v5.md\nindex c5b8bc6..20b05b1 100755\n--- a/v4.md\n+++ b/v5.md\n@@\n-Location: Murcia, Spain (CET, UTC+1)\n+Location: Murcia, Spain (CET, UTC+2)\n@@\n-**Status**: Will merge to `next`.\n+**Status**: merged to `next` on 2026-03-13 at f545ea5a9c.\n@@\n+[[GSoC PATCH v6 0/3] graph: add --graph-lane-limit\noption](https://lore.kernel.org/git/20260328001113.1275291-1-pabloosabaterr@gmail.com/)\n+\n+**Status**: WIP.\n+\n+**Description**: Adds `--graph-lane-limit` option to `--graph` to\nlimit the number of horizontal lanes that will be shown. Helps\nreadability for projects with many branches.\n+\n+[[GSoC PATCH 0/3] receive-pack: fix HEAD check for\nupdateInstead](https://lore.kernel.org/git/20260330111822.165188-1-pabloosabaterr@gmail.com/)\n+\n+**Status**: pending review.\n+\n+**Description**: Fix updateInstead HEAD check that only looked for\nthe bare repo context instead of the worktree HEAD, which rejected the\npushes even with the wt clean.\n+\n+## Code Reviews\n+\n@@\n-**Description**: Code review for a patch sent.\n+**Description**: Code review for a patch sent about simplifying a\nduplicated code.\n+\n+[Re: [PATCH] t2107: modernize path existence\ncheck](https://lore.kernel.org/all/CAN5EUNTNqC6+FPjKafoFfgaEzWdpXEV0QNwumF8CaxBEUOmA6Q@mail.gmail.com/)\n@@\n-[[GSoC RFC PATCH] graph: add --graph-max option to limit displayed\ncolumns](https://lore.kernel.org/git/20260316133426.117684-1-pabloosabaterr@gmail.com/)\n+[Re: [GSoC][PATCH] t2000: modernize path checks to use helper\nfunctions](https://lore.kernel.org/all/CAN5EUNTSO7KvtO02c-EHJTK95rmcZKRBtKsn8kjNid1qupWZ0w@mail.gmail.com/)\n@@\n-**Status**: RFC, waiting for feedback.\n+[Re: [PATCH] t5315: use test_path_is_file for loose-object\ncheck](https://lore.kernel.org/all/CAN5EUNR2mqpCMG0oPsDnzgZr-2yyL+S0A7p_MM62F7d4MjBuSA@mail.gmail.com/)\n@@\n-**Description**: Adds `--graph-max` option to `git log --graph` to\ncap the number of columns that will be displayed. Helps readability\nfor projects with many branches.\n+**Description**: Reviews to newcomers on their microprojects patches.\n@@\n-I'm being active on the mailing list and learning the Git flow of\nwork and from the feedback I've received from the maintainers (Junio)\nfrom my patches.\n+I'm being active on the mailing list, learning the Git flow of work\nand learning from the feedback I've received from the maintainers on\nmy patches and reviewing others.\n"}]}