{"thread":{"id":"65270","subject":"[GSOC][RFC] Draft Proposal: Complete and extend the remote-object-info command for git cat-file","startedAt":"2026-03-16T19:59:03Z","lastAt":"2026-03-24T15:50:47Z","messageCount":4,"participants":["Deveshi Dwivedi","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"539153","messageId":"CAG7UgEQTPhxPeEYkm44+BuSj5GG6PWhRrqGT7Vq7zXFPKZqoag@mail.gmail.com","threadId":"65270","inReplyTo":null,"subject":"[GSOC][RFC] Draft Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Deveshi Dwivedi","fromEmail":"deveshigurgaon@gmail.com","sentAt":"2026-03-16T19:58:48Z","receivedAt":"2026-03-16T19:59:03Z","isPatch":false,"body":"Hi! I would be grateful to get feedback on my proposal draft for GSoC\n2026. Thank you very much!\n-----------------------------------------------------------------------\n\nComplete and extend the remote-object-info command for git cat-file\n\n-----------------------------------------------------------------------\n\nPersonal Information\n\nName: Deveshi Dwivedi\nEmail: deveshigurgaon@gmail.com\nGitHub: https://github.com/deveshidwivedi\nTime Zone: UTC +5:30 (IST)\nEducation: Final year, IIIT Jabalpur\nBlog: https://deveshidwivedi.github.io\n\n-----------------------------------------------------------------------\n\nPast experience with Open Source\n\nI have been contributing to open source for the past few years. My\nfirst contribution was during my second year of college. Since then I\nhave tried contributing to different projects to get better at\nnavigating unfamiliar codebases and understanding how real-world\nprojects are maintained. Some of my contributions include:\n\n- https://github.com/processing/p5.js-web-editor/pull/3492\n\n- https://github.com/neovim/neovim/pull/33235\n\n- https://github.com/kube-vip/kube-vip/pull/1087\n\n- https://github.com/WasmEdge/WasmEdge/pull/3963\n\n- https://github.com/openfoodfacts/openfoodfacts-server/pull/10037\n\n- https://github.com/openfoodfacts/openfoodfacts-server/pull/9967\n\n- https://github.com/processing/p5.js/pull/6761\n\n- https://github.com/processing/p5.js/pull/6669\n\nI was also grateful to be an LFX mentee in Summer 2024 under the Open\nMainframe Project. During the program I worked on building a new\nfrontend for the Software Discovery Tool and integrating it with the\nbackend to make the tool easier to use.\n\n-----------------------------------------------------------------------\n\nMy contributions so far\n\n*t5403: use test_path_is_file instead of test -f\n*Mailing list: https://lore.kernel.org/git/20251229185737.2328-1-deveshigurgaon@gmail.com/\n*Status: merged in 'master'\n*Description: Replace test -f with test_path_is_file helper in\npost-checkout hook test for better failure diagnostics.\n\n*t5403: improve post-checkout hook testing\n*Mailing list: https://lore.kernel.org/git/20260112163643.231-1-deveshigurgaon@gmail.com/\n*Status: merged in 'master'\n*Description: Introduce check_post_checkout helper to eliminate\nrepetitive hook validation patterns, then switch to test_cmp for\nclearer argument mismatch diagnostics.\n\n*t1006: fix %(rest) test for object names with whitespace\n*Mailing list: https://lore.kernel.org/git/20260219152407.12160-1-deveshigurgaon@gmail.com/\n*Status: dropped\n*Description: Submitted a patch to address a FIXME in t1006 around\n%(rest) behavior with whitespace in object names. Junio explained that\nwhitespace-as-delimiter is documented behavior for %(rest), not a bug,\nand Victoria clarified the FIXME was intentionally documenting a known\nlimitation, not requesting a fix. This taught me to read test comments\nin their full historical context rather than treating them as isolated\ntasks. It also introduced me to t1006-cat-file.sh in depth, which is\ndirectly relevant to this project.\n\n*avoid unnecessary strbuf_split*() and strbuf-by-value usage\n*Mailing list: https://lore.kernel.org/git/20260311173336.8395-1-deveshigurgaon@gmail.com/\n*Status:Will merge to 'master'\n*Description: Eliminate inefficient strbuf_split_str() in combine\nfilter parsing by using direct string traversal with strchrnul(), and\nconvert write_worktree_linking_files() to accept path strings instead\nof strbuf-by-value parameters.\n\n*coccinelle: detect and fix strbuf-by-value parameters\n*Mailing list: https://lore.kernel.org/git/20260315094445.19849-1-deveshigurgaon@gmail.com/\n*Status: queued\n*Description: Add Coccinelle semantic patch to automatically detect\nfunctions taking struct strbuf by value, transforming them to pointer\nparameters and fix the remaining instance in stash.c.\n\n-----------------------------------------------------------------------\n\nProject Overview\n\nThis project completes and extends the remote-object-info subcommand\nfor git cat-file --batch-command, which allows clients to request\nobject metadata from a remote without downloading full object\ncontents.\n\nGoal 1: Rebase and finalize Eric Ju's v11 patch series [1], address\nthe remaining review feedback, and get it merged.\nGoal 2: Add %(objecttype) support to the object-info protocol, end-to-end.\n\n-----------------------------------------------------------------------\n\nProposed Solution\n\n----------\n\nGoal 1: Complete v11 Series\n\n----------\n\nPre-GSoC Analysis:\n\nI rebased Eric Ju's v11 series [1] onto the current master. There were\nconflicts in t/t1006-cat-file.sh, fetch-pack.c, Makefile and\nobject-file.c. After resolving those and building, I ran the test\nsuite.\n\nWhile running t/t1017-cat-file-remote-object-info.sh [2], the first\ntest failed with \"ambiguous redirect\". '$daemon_parent' expands to the\ntrash directory path which contains a space and the redirect is not\nquoted:\n\necho_without_newline \"$hello_content\" > $daemon_parent/hello\n\nThe shell splits on the space and does not know which file to redirect\nto. I grepped for other unquoted uses and found the same problem with\n$HTTPD_DOCUMENT_ROOT_PATH/http_parent/hello in the http test section.\nThis is fixed once we quote both the instances.\n\nIn review of Calvin Wan's initial remote-object-info implementation\n[3], Jonathan Tan observed that the remote-object-info state\nis currently stored in static globals rather than in the shared\ncommand data structure. This approach makes it difficult to support\nmixing commands in a batch session. The v11 series addressed most of\nthis by restructuring the code so that remote-object-info now goes\nthrough the same expand_data path used by info. However, one instance\nof shared state mutation still remains.\n\nIn get_remote_info(), when no explicit format is given, currently the code does:\n\nif (!opt->format)\n    opt->format = \"%(objectname) %(objectsize)\";\n\nThe problem is that opt->format is shared across all commands in the\nbatch session. batch_objects() creates a single expand_data structure,\nwhich every command uses. Mutating opt->format here permanently\nreplaces the original NULL value.\n\nFix: Instead of modifying the shared state,  we can use a local\nvariable in parse_cmd_remote_object_info():\n\nconst char *remote_format = opt->format\n    ? opt->format\n    : \"%(objectname) %(objectsize)\";\n\nand pass remote_format to get_remote_info() for validation. This fix\nis needed regardless of Goal 2. Even when the values happen to match,\nmutating shared state from a command handler is incorrect. Once\n%(objecttype) support is added, the special-case default disappears\nentirely, and both local and remote commands can simply use\nDEFAULT_FORMAT.\n\n----------\n\nReview Feedback Analysis\n\nBelow are the main issues raised during the v11 review of the\nremote-object-info patch series and how I plan to address them:\n\nIssue 1: Format Validation Segfault [4]\nThe current validation uses a strstr() check to ensure that the format\ncontains %(objectsize). This is not sufficient. A format like:\n\n%(objecttype) %(objectsize)\n\npasses the check but later causes a segfault.\nThe crash occurs in expand_atom():\n\nstrbuf_addstr(sb, type_name(data->type));\n\nThe call chain looks like this:\n\nbatch_objects_command()\n  → parse_cmd_remote_object_info()\n    → get_remote_info()           ← validation belongs here\n      → transport_fetch_refs()\n    → batch_object_write()\n      → expand_format()\n        → expand_atom()           ← segfault here\n\nThe problem is that data->type may never be initialized. When it\nremains OBJ_NONE (0), type_name(0) returns NULL because\nobject_type_strings[0] is NULL. That NULL is then passed to\nstrbuf_addstr(), which dereferences it and segfaults.\nJeff King pointed this out during review [4]. While experimenting with\nthe feature, he tried:\n\ngit cat-file --batch-command='%(objecttype) %(objectsize)'\n\nand feeding it a remote-object-info request, which triggered the\ncrash. I was able to reproduce the same behavior locally using a\nsimple client/server setup and a blob from a test repository.\n\nFix: Instead of relying on a strstr() check, the validation should\ndetermine which atoms were actually requested by the format. During\nthe mark-query phase, expand_format() records requested atoms by\npopulating the corresponding fields in data.info. After this stage we\ncan inspect those fields to see exactly which atoms were requested.\n\nIf the format asks for something remote-object-info cannot provide,\nthe command should exit with an error that names the unsupported atom.\nThe format is defined when the batch session starts, so requesting an\nunsupported atom is a configuration error rather than a per-object\ncondition. Returning empty output would be misleading, since a caller\nwould not be able to tell whether the object actually lacks that\nattribute or the protocol simply does not support it. Failing early\nwith a clear error avoids silently producing incorrect results.\n\nImplementing this validation requires passing the expand_data instance\ndown to get_remote_info(). In v11 the function currently has the\nsignature:\n\nstatic int get_remote_info(struct batch_options *opt, int argc, const\nchar **argv)\n\nFor this check to work, the expand_data pointer needs to be threaded\nthrough from parse_cmd_remote_object_info(). This ends up being the\nsame signature change required for the format-mutation fix described\nearlier, so both fixes can share the same small refactor.\n\nAs an additional safety measure, a defensive guard can be added in\nexpand_atom() so that it cannot segfault even if validation is\nbypassed in a future code path.\n\nFinally, the EXPAND_DATA_INIT macro currently initializes only .mode =\nS_IFINVALID. It should also initialize .type = OBJ_BAD. Since OBJ_BAD\nis -1, outside the bounds of the object_type_strings array,\ntype_name() will return NULL, which is then safely handled by the\nguard above.\n\nIssue 2: Misleading Input Overflow Error [5]\n\nThe current overflow check reports that the command contains too many\nobjects, but that may not be the real cause. For example, a very long\nrepository URL could exceed the line length limit and trigger the same\nerror. Junio pointed this out in his review [5].\n\nFix: We can handle this with two separate validation steps.\n\nFirst,we can check the line length before parsing and report any\noverflow accurately. After parsing, we can validate the number of\nrequested objects. Malformed quoting should also be caught during\nparsing. Separating these checks ensures that error messages point to\nthe actual problem, rather than incorrectly blaming too many objects.\n\nIssue 3: Code Style and State Management\n\nThe patch series also introduces a few style inconsistencies that\nshould be cleaned up:\n- multi-line comment formatting\n- missing blank lines between #define groups\n- long macro definitions\n- mixing size_t and int for loop counters\n\nIn addition, parse_cmd_remote_object_info() should reset all fields in\nexpand_data that it modifies before returning. The v11 implementation\nalready resets data->skip_object_info = 0 on both normal and error\npaths, but it does not reset data->type or data->size. Resetting these\nfields avoids leaking stale remote state into subsequent commands.\n\ndata->skip_object_info = 0; (already in v11)\ndata->type = OBJ_BAD;\ndata->size = 0;\n\nWithout these resets, a batch session that runs remote-object-info\nfollowed by a local info command could produce incorrect output. If\nodb_read_object_info_extended() fails for the local object, the\npreviously populated remote values may still be present in data,\ncausing stale data to be printed. It is also important that the\ndata->skip_object_info = 0 reset happens even on the goto cleanup\nerror path so that the state is fully restored before returning.\n\nNew tests to be added for v12:\n- %(objecttype) %(objectsize) format: command dies cleanly instead of\nsegfaulting\n- %(objecttype) alone: command dies with a clear error\n- %(objectname) only: works without requesting size\n- Mixed remote-object-info and info commands in batch mode: both use\nthe correct default formats (this also catches the format-mutation\nissue)\n\n----------\nGoal 2: Add support for %(objecttype)\n----------\nServer Side\n\nstruct requested_info in protocol-caps.c is extended to include\nunsigned type : 1, alongside the existing unsigned size : 1. The\ncapability parser in cap_object_info() is updated to recognize type\nrequests using the same pattern that is already used for size. The\nserver-side response logic in send_info() is then updated to include\nthe type when it has been requested.\n\nOne useful optimization here is that odb_read_object_info() already\nprovides the object type as its return value, while the object size is\nreturned through an output parameter. The current implementation in\nsend_info() calls this function but discards the return value after\nchecking whether it is negative. When both size and type are\nrequested, we can obtain both pieces of information from a single\ncall. If only type is requested, the call simply passes NULL for the\nsizep parameter.\n\nFor loose objects, both the type and size are stored in the same\nobject header (\"<type> <size>\\0\"). For packed objects, the type is\nalready in the pack entry header, so retrieving it is free.\n\nWhen sending responses, send_info() includes both size and type in the\nheaders if requested. Each object line looks like:\n\n<oid> <size> <type>\n\nIf the server cannot resolve an attribute, that field is left blank.\nBehavior for missing values remains consistent with existing handling.\n\nOn the server side, object_info_advertise() in serve.c no longer marks\nits struct strbuf *value as UNUSED and now populates it with \"size\ntype\". This means the server advertises:\n\nobject-info=size type\n\nduring capability negotiation. Older clients ignore the value string\nper protocol v2 rules, and the server_supports_v2(\"object-info\") check\ncontinues to work, so backward compatibility is maintained.\n\n----------\n\nClient Transport\n\nBefore requesting type, the client checks whether the server supports\nit using server_supports_feature(\"object-info\", \"type\", 0). This looks\nat the capability value and parses it with parse_feature_request(). If\nthe server advertises only object-info=size, the check returns false\nfor type. In that case, if the format requires %(objecttype), the\nclient exits with a clear error. When building the request,\nunsorted_string_list_has_string() is used instead of strstr() to avoid\nsubstring matches.\n\nOn the response side, the client keeps track of column positions using\nsize_index and type_index, both initialized to -1. The attribute\nheaders sent by the server determine which columns appear and in what\norder. The data lines are then parsed using those indices with bounds\nchecks. Since column 0 is always the OID, the indices use a +1 offset.\nFor example: in <oid> 1234 blob, column 1 contains the size and column\n2 contains the type. If fewer columns are returned than expected, the\nbounds checks prevent out-of-range access.\n\n----------\n\nMemory: I will allocate typep per OID the same way v11 already does\nfor sizep; free_object_info_contents() handles cleanup.\n\n----------\n\ncat-file integration\n\nIn get_remote_info(), the format string determines which attributes\nare requested from the server. Previously, if %(objectsize) appeared\nin the format, \"size\" was added to object_info_options. With this\nchange, %(objecttype) similarly adds \"type\".\n\nSince %(objecttype) is now supported, the earlier allow-list\nvalidation that rejected data->info.typep is removed.\n\nSupporting %(objecttype) also allows the removal of the special-case\ndefault format in get_remote_info(). Both local and remote commands\ncan now use DEFAULT_FORMAT (%(objectname) %(objecttype)\n%(objectsize)), eliminating the previous mismatch in default output.\n\n----------\n\nBackward Compatibility:\n\nA new client with a new server supports both size and type. With a new\nclient and an old server, server_supports_feature() returns false for\ntype, and the client exits with a clear error if the format requests\n%(objecttype). Size-only requests still work. Old clients work with\nany server. They ignore the new type capability and only request the\nattributes they understand, so existing workflows continue to work as\nbefore.\n\n----------\n\nTesting for Goal 2\n\nServer-side (t/t5701-git-serve.sh):\n\nServer advertises object-info=size type\nCorrect type strings for all four object types\nCombined size + type and type-only requests\n\nClient-side (t/t1017-cat-file-remote-object-info.sh):\n\n%(objecttype) across git://, file://, http://\nDefault format includes type after unification\nServer that only supports size: clean error for %(objecttype)\nMixed local + remote in buffer mode (state isolation)\n\n----------\n\nStretch Goals (if time permits)\n\nIf Goal 1 and Goal 2 land ahead of schedule, %(objectsize:disk) could\nbe explored. The server infrastructure already exists via\nodb_read_object_info_extended() and the implementation pattern is\nidentical to %(objecttype). %(deltabase) is a similar extension. Both\ndepend on server pack format rather than intrinsic object properties,\nso either would need mailing list consensus before proceeding.\n\n-----------------------------------------------------------------------\n\nProject Timeline\n\nI have intentionally allocated slightly longer phase intervals to\nprovide a buffer. In practice, each task may take less time, but this\nensures there is room to handle unexpected delays without affecting\nthe overall schedule.\n\nPre-GSoC (Until May 1):\n- Continue exploring the codebase.\n- Stay engaged with the community and follow discussions.\n\nCommunity Bonding (May 1 - 25):\n- Study the codebase and internals in more depth.\n- Review all v11 feedback threads.\n- Identify rebase conflicts.\n- Discuss protocol design with mentors on the mailing list.\n\nPhase 1: Rebase and Fix (May 26 - Jun 15):\n- Rebase v11 onto master.\n- Fix all bugs: format validation, input validation, format mutation,\nstate cleanup, code style, test quoting.\n- Add new tests.\n- Send v12 to the mailing list.\n\nPhase 2 (Jun 16 - Jul 6):\n- Iterate on v12 review feedback.\n- Begin server-side type implementation.\n- Add server tests, send server patches.\n\nMidterm (Jul 10):\n- Goal 1 in final review or merged.\n- Server patches posted.\n\nPhase 3: Client and Integration (Jul 14 - Aug 10):\n- Iterate on server patches.\n- Implement client transport and cat-file integration.\n\nPhase 4: Final (Aug 11 - 24):\n- Final review iteration.\n- Buffer for unexpected issues.\n- Ensure all patches are in the review pipeline.\n\nFinal Evaluation (Aug 25 - 31):\n- Address any remaining review feedback.\n\n-----------------------------------------------------------------------\n\nAvailability\n\nThe project size is 350 hours (medium). I plan to dedicate around 35\nhours per week during the 12-week coding period to work on the\nproject. I do not anticipate any major conflicts during this time and\nwill be able to stay actively engaged with development and\ndiscussions.\n\n-----------------------------------------------------------------------\n\nPost GSoC\n\nI would like to stay active in the Git community even after GSoC.\nThere is still a lot for me to learn from the project and the\ncommunity, and I hope to continue contributing and improving my\nunderstanding of Git’s internals.\n\n-----------------------------------------------------------------------\n\nReferences\n\n[1] https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/\n\n[2] https://lore.kernel.org/git/20240628190503.67389-7-eric.peijian@gmail.com/\n\n[3] https://lore.kernel.org/git/20220504212738.162853-1-jonathantanmy@google.com/\n\n[4] https://lore.kernel.org/git/20240628190503.67389-1-eric.peijian@gmail.com/t/#md20501dc269cc38ac1ac8cf7599281b937b651a0\n\n[5] https://lore.kernel.org/git/20240628190503.67389-1-eric.peijian@gmail.com/t/#mbe53f476d6cd32633277c28f17f8b6a59316b1db\n\n--\nThank you,\nDeveshi\n"},{"id":"539826","messageId":"CAP8UFD1Kirbt-j5h7NB0UcxPjz=Ger7GBK+excY4Z8X+yKtdzw@mail.gmail.com","threadId":"65270","inReplyTo":"CAG7UgEQTPhxPeEYkm44+BuSj5GG6PWhRrqGT7Vq7zXFPKZqoag@mail.gmail.com","subject":"Re: [GSOC][RFC] Draft Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-24T10:42:00Z","receivedAt":"2026-03-24T10:42:13Z","isPatch":false,"body":"Hi,\n\nOn Mon, Mar 16, 2026 at 8:59 PM Deveshi Dwivedi\n<deveshigurgaon@gmail.com> wrote:\n>\n> Hi! I would be grateful to get feedback on my proposal draft for GSoC\n> 2026.\n\nSorry for the late feedback, and thanks for your interest in Git and\nthis project.\n\n[...]\n\n> - https://github.com/processing/p5.js-web-editor/pull/3492\n>\n> - https://github.com/neovim/neovim/pull/33235\n>\n> - https://github.com/kube-vip/kube-vip/pull/1087\n>\n> - https://github.com/WasmEdge/WasmEdge/pull/3963\n>\n> - https://github.com/openfoodfacts/openfoodfacts-server/pull/10037\n>\n> - https://github.com/openfoodfacts/openfoodfacts-server/pull/9967\n>\n> - https://github.com/processing/p5.js/pull/6761\n>\n> - https://github.com/processing/p5.js/pull/6669\n\nIt could be interesting to introduce these contributions a bit more.\nMaybe for example add one sentence to introduce your contributions to\np5.js and one to introduce your contributions to openfoodfacts-server.\n\n> I was also grateful to be an LFX mentee in Summer 2024 under the Open\n> Mainframe Project. During the program I worked on building a new\n> frontend for the Software Discovery Tool and integrating it with the\n> backend to make the tool easier to use.\n\nDo you have a link about this?\n\nThanks for your proposal.\n\nBest,\nChristian.\n"},{"id":"539850","messageId":"CAG7UgES4Vm9yboUk1nnPKHBdMu17gt-2dh9VmXD_=Lpc3o+3Jw@mail.gmail.com","threadId":"65270","inReplyTo":"CAP8UFD1Kirbt-j5h7NB0UcxPjz=Ger7GBK+excY4Z8X+yKtdzw@mail.gmail.com","subject":"Re: [GSOC][RFC] Draft Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Deveshi Dwivedi","fromEmail":"deveshigurgaon@gmail.com","sentAt":"2026-03-24T15:45:52Z","receivedAt":"2026-03-24T15:46:08Z","isPatch":false,"body":"> > - https://github.com/processing/p5.js-web-editor/pull/3492\n> >\n> > - https://github.com/neovim/neovim/pull/33235\n> >\n> > - https://github.com/kube-vip/kube-vip/pull/1087\n> >\n> > - https://github.com/WasmEdge/WasmEdge/pull/3963\n> >\n> > - https://github.com/openfoodfacts/openfoodfacts-server/pull/10037\n> >\n> > - https://github.com/openfoodfacts/openfoodfacts-server/pull/9967\n> >\n> > - https://github.com/processing/p5.js/pull/6761\n> >\n> > - https://github.com/processing/p5.js/pull/6669\n>\n> It could be interesting to introduce these contributions a bit more.\n> Maybe for example add one sentence to introduce your contributions to\n> p5.js and one to introduce your contributions to openfoodfacts-server.\n>\n\nSure, I will add relevant introductions for these contributions.\n\n> > I was also grateful to be an LFX mentee in Summer 2024 under the Open\n> > Mainframe Project. During the program I worked on building a new\n> > frontend for the Software Discovery Tool and integrating it with the\n> > backend to make the tool easier to use.\n>\n> Do you have a link about this?\n>\n\nYes, I will add links to my contributions from the program. Thank you\nfor taking the time to review my proposal. I will incorporate the\nsuggested changes.\n\n> Thanks for your proposal.\n>\n> Best,\n> Christian.\n\nThank you very much for your\n\nOn Tue, 24 Mar 2026 at 16:12, Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi,\n>\n> On Mon, Mar 16, 2026 at 8:59 PM Deveshi Dwivedi\n> <deveshigurgaon@gmail.com> wrote:\n> >\n> > Hi! I would be grateful to get feedback on my proposal draft for GSoC\n> > 2026.\n>\n> Sorry for the late feedback, and thanks for your interest in Git and\n> this project.\n>\n> [...]\n>\n> > - https://github.com/processing/p5.js-web-editor/pull/3492\n> >\n> > - https://github.com/neovim/neovim/pull/33235\n> >\n> > - https://github.com/kube-vip/kube-vip/pull/1087\n> >\n> > - https://github.com/WasmEdge/WasmEdge/pull/3963\n> >\n> > - https://github.com/openfoodfacts/openfoodfacts-server/pull/10037\n> >\n> > - https://github.com/openfoodfacts/openfoodfacts-server/pull/9967\n> >\n> > - https://github.com/processing/p5.js/pull/6761\n> >\n> > - https://github.com/processing/p5.js/pull/6669\n>\n> It could be interesting to introduce these contributions a bit more.\n> Maybe for example add one sentence to introduce your contributions to\n> p5.js and one to introduce your contributions to openfoodfacts-server.\n>\n> > I was also grateful to be an LFX mentee in Summer 2024 under the Open\n> > Mainframe Project. During the program I worked on building a new\n> > frontend for the Software Discovery Tool and integrating it with the\n> > backend to make the tool easier to use.\n>\n> Do you have a link about this?\n>\n> Thanks for your proposal.\n>\n> Best,\n> Christian.\n"},{"id":"539852","messageId":"CAG7UgETAU6Pn0t_HOdQphdT4r6Sa88D0OFiqCcOuv3_uxjUaWA@mail.gmail.com","threadId":"65270","inReplyTo":"CAG7UgES4Vm9yboUk1nnPKHBdMu17gt-2dh9VmXD_=Lpc3o+3Jw@mail.gmail.com","subject":"Re: [GSOC][RFC] Draft Proposal: Complete and extend the remote-object-info command for git cat-file","fromName":"Deveshi Dwivedi","fromEmail":"deveshigurgaon@gmail.com","sentAt":"2026-03-24T15:50:32Z","receivedAt":"2026-03-24T15:50:47Z","isPatch":false,"body":"Apologies for the incomplete email I sent earlier. Thank you very much\nfor reviewing my proposal.\n"}]}