{"thread":{"id":"66766","subject":"[Outreachy] Project Proposal : Implement promisor remote fetch ordering","startedAt":"2026-11-04T10:26:43Z","lastAt":"2026-11-05T00:03:46Z","messageCount":4,"participants":["Shashank S","Usman Akinyemi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"557422","messageId":"CANHmUQTDpwW7N7axexos32PxvPBPB10NFSpM1bUiKAbk3SMSyw@mail.gmail.com","threadId":"66766","inReplyTo":null,"subject":"[Outreachy] Project Proposal : Implement promisor remote fetch ordering","fromName":"Shashank S","fromEmail":"shashu8660@gmail.com","sentAt":"2026-11-04T10:26:43Z","receivedAt":"2026-11-04T10:26:43Z","isPatch":false,"sender":{"key":"shashu8660@gmail.com","avatar":null},"body":"Hi,\n\nThis is my proposal for the project \"Implement promisor remote fetch\nordering\" for the December 2026 Outreachy internship.\n\nI would appreciate any feedback from the community.\n\nPersonal Information\n----------------------------\n\nFull Name: Shashank S Mogaveera\nEmail Address : shashu8660@gmail.com\nGithub : https://github.com/shashu8660\nLocation : Kundapur, Karnataka, India (IST, UTC+5:30)\n\nAbout me\n-------------\n\nI am Shashank, a software engineer with a strong passion for C\nprogramming, system architecture, and network protocols. My journey\ninto open-source development began with a desire to understand how\nmassive, distributed systems operate under the hood.\n\nDuring this Outreachy contribution phase, I initially focused on Git's\ncore libification and option-parsing APIs, which allowed me to get\ncomfortable modifying Git's C structs and internal memory management.\nHowever, my true interest lies in network optimization. Diving into\nGit's GIT_TRACE2 engine to map out how partial clones communicate with\npromisor remotes convinced me that the \"Implement promisor remote\nfetch ordering\" project is exactly where I want to focus my 13-week\ninternship.\n\nPast experience with git\n--------------------------------\n\nI have been using Git extensively for version control in my personal\nprojects. This contribution period was my first time engaging directly\nwith a mailing list-based open-source community.\n\nLearning to use git send-email and GitGitGadget to format patches,\nmanage versioned rerolls (v1, v2), and incorporate maintainer feedback\nhas been a massive learning curve, but a highly rewarding one. I\nlearned the importance of atomic commits, clean commit messages, and\nthe strict rules around not ignoring Git's exit codes in shell\nscripts.\n\n\nContribution to the git community\n--------------------------------------------\n\nMicroprojects:\n\n1.  t0081: modernize the code testing whether a file exists\n     Link: https://lore.kernel.org/git/pull.2254.git.1791962806807.gitgitgadget@gmail.com/\n     This patch series was integrated into master via\ngithttps://github.com/git/git/commit/e1bb515788e48d500c9d4e36f13c66c4daddd3d4\n\n2.  t2403: modernize test for directory existence\n      Link: https://lore.kernel.org/git/pull.2259.git.1792125111461.gitgitgadget@gmail.com/\n      This patch series was integrated into seen via\nhttps://github.com/git/git/commit/c645a5db002ded161115dc8f6c15a40acfdde2b2\n\n3. prune-packed: remove use_the_repository_variable\n    Link :https://lore.kernel.org/git/pull.2266.git.1792341073005.gitgitgadget@gmail.com/\n    This patch series was integrated into next via\nhttps://github.com/git/git/commit/936609cfa0a57e1b047c345a91fec79ab255897c\n\n4. test-chmtime: use parse_options() to parse command-line flags\n    Link: https://lore.kernel.org/git/pull.2280.git.1793099688076.gitgitgadget@gmail.com/\n    This patch series was integrated into seen via\nhttps://github.com/git/git/commit/c6a318cc4b8c6f6ce1a403e497816cd195c57cf7\n\nProject Overview: Promisor Remote Fetch Ordering\n----------------------------------------------------------------------\nWhen a Git repository is configured as a partial clone with multiple\npromisor remotes, there is currently no defined mechanism to specify\nthe order in which these remotes should be queried for missing\nobjects.\n\nDifferent remotes have vastly different performance characteristics\nand bandwidth costs. Currently, Git relies on a hardcoded fallback\nsystem rather than deterministic priority. This project aims to\nimplement a flexible fetch ordering mechanism by introducing a\nclient-side configuration list (promisor.fetchOrder) and a server-side\nadvertisement extension via Git Protocol v2, allowing servers to\nbroadcast their preferred fetch order.\n\nPhase 0: Baseline & Trace2 Playground Verification\n----------------------------------------------------------------------\nBefore designing the protocol enhancements, I established a verifiable\nbaseline by building a local partial clone playground with multiple\ndummy promisor remotes (server-A and server-B).\n\nTo prove the telemetry, I forced a lazy fetch by requesting a missing\nobject (file2.txt) and captured the transaction using\nGIT_TRACE2_EVENT.\n\n- Verification: I successfully extracted the\n{\"key\":\"fetch_count\",\"value\":\"1\"} data event and the specific\nchild_start subprocess ([\"git\",\"fetch\",\"origin\"...]) proving which\nremote Git communicated with first.\n\nThe Current Baseline (Ordering Rules): Git currently lacks a\ndeterministic, user-configurable fetch order for multiple promisor\nremotes. Based on my trace testing and codebase review, the baseline\nbehavior is:\n\n- By default, Git iterates through configured remotes in the order\nthey are stored/parsed when attempting to fetch missing objects.\n\n- The remote configured via core.partialClone (usually origin) is\ntreated strictly as a fallback and is checked last.\n\n- If a remote fails, Git moves to the next available promisor remote\nuntil the missing object is found or all remotes are exhausted.\n\nInternship Plan and 13-Week Timeline\n---------------------------------------------------\n\nPre-Internship (Now – Dec 6)\n-----------------------------------------\nFinish resolving feedback on my test-chmtime.c (v2) and prune-packed.c\npatches.Study the promisor-remote.c sorting algorithms and Git\nProtocol v2 documentation.\n\nWeeks 1–2 (Dec 7 – Dec 20): Phase 1 - Visibility and Baseline\n-------------------------------------------------------------------------------------\nGoal: Document and lock in Git's current behavior to act as a safety net.\n\nTasks: Submit a docs-only upstream patch defining the current fallback\nrules (accepted before configured, partialClone last, fallback on\nfailure). Develop automated tests utilizing GIT_TRACE2 to definitively\nlock in and prove the current sequential fetch order.\n\nWeeks 3–5 (Dec 21 – Jan 10): Phase 2 - Client-Side Ordering\n------------------------------------------------------------------------------------\nGoal: Implement local configuration for promisor remote priorities.\n\nTasks: Introduce the promisor.fetchOrder configuration list. A list is\npreferred over per-remote integers as it composes cleanly across\nconfig files. Refactor internal sorting logic in promisor-remote.c to\nreorder remotes based on this list before initiating lazy fetches.\nImplement edge-case handling for unlisted remotes and preserve the\npartialClone-last fallback rule.\n\nWeeks 6–9 (Jan 11 – Feb 7): Phase 3 - Server-Advertised Order\n--------------------------------------------------------------------------------------\nGoal: Extend Protocol v2 to allow servers to broadcast their preferred priority.\n\nTasks: Draft an RFC proposing the protocol v2 explicit priority=<n>\nfields. Implement server-side advertisement gated by a new\npromisor.sendFields configuration. Implement the client-side parser,\nstrictly adhering to the \"ignore unknown fields\" rule to maintain\nbackward compatibility.\n\nWeeks 10–12 (Feb 8 – Feb 28): Phase 4 - Upstreaming & Precedence\n-----------------------------------------------------------------------------------------------\nGoal: Secure mailing list approval and resolve precedence rules.\n\nTasks: Settle precedence conflicts (Recommendation: local client\nconfig maintains absolute authority, while the server's advertised\norder sorts unranked remotes). Split Phase 2 and Phase 3 into a clean,\nreviewable patch series. Route through at least two rounds of mailing\nlist review.\n\nWeek 13 (Mar 1 – Mar 8): Polish & Stretch Goals\n-------------------------------------------------------------------\nGoal: Finalize documentation and explore dynamic caching.\n\nTasks: Write final release notes and user-facing documentation.\nStretch Goal: Implement runtime memory of failed remotes within a\nsingle process to skip them on subsequent lazy fetches to reduce\nlatency. Submit final Outreachy report.\n\nAvailability\n------------------\nI can commit 40 hours a week to the project during the internship. I\nam based in India (IST, UTC+5:30) and can adjust my hours for\nsynchronous calls, pair programming, and mailing list reviews to\noverlap with my mentors' timezones.\n\nBlogging\n-------------\nI will document my technical journey, posting weekly updates on the\nC-level challenges I face, how I navigate network tracing, and the\nfeedback I receive from the Git community. I will share each post on\nthe mailing list.\n\nAfter the Internship\n---------------------------\nAfter the internship, I intend to remain an active contributor to the\nGit core project. Having touched the libification, option parsing, and\nnetwork protocol subsystems during my application, I want to continue\nbridging these areas—specifically helping remove the remaining\nUSE_THE_REPOSITORY_VARIABLE macros from network-facing C files like\npromisor-remote.c.\n\nAppreciation\n-------------------\nI want to express my gratitude to Usman Akinyemi, Junio C Hamano,\nKaartic Sivaraam, Patrick Steinhardt and Cynthia Uche. Your patience\nin reviewing my early patches and helping me understand the git\nsend-email workflow has been incredible. Thank you for making this\ncommunity so welcoming.\n\nThank you .\n\n"},{"id":"557424","messageId":"CANHmUQSBs=Mq1Y1GTY6P9FtyCQz58bDWFgJPgwv4r5rLP3C1Bg@mail.gmail.com","threadId":"66766","inReplyTo":"CANHmUQTDpwW7N7axexos32PxvPBPB10NFSpM1bUiKAbk3SMSyw@mail.gmail.com","subject":"Re: [Outreachy] Project Proposal : Implement promisor remote fetch ordering","fromName":"Shashank S","fromEmail":"shashu8660@gmail.com","sentAt":"2026-11-04T10:46:03Z","receivedAt":"2026-11-04T10:46:03Z","isPatch":false,"sender":{"key":"shashu8660@gmail.com","avatar":null},"body":"On Wed, 4 Nov 2026 at 15:56, Shashank S <shashu8660@gmail.com> wrote:\n\nI am sending a quick follow-up to correct a typo in the CC line for\nKaartic, and to fix the links to my microprojects from my proposal\n(the URLs were accidentally joined with the text in my previous\nemail).\n\n> Microprojects:\n>\n> 1.  t0081: modernize the code testing whether a file exists\n>      Link: https://lore.kernel.org/git/pull.2254.git.1791962806807.gitgitgadget@gmail.com/\n>      This patch series was integrated into master via\n> githttps://github.com/git/git/commit/e1bb515788e48d500c9d4e36f13c66c4daddd3d4\n\nhttps://github.com/git/git/commit/e1bb515788e48d500c9d4e36f13c66c4daddd3d4\n\n>\n> 2.  t2403: modernize test for directory existence\n>       Link: https://lore.kernel.org/git/pull.2259.git.1792125111461.gitgitgadget@gmail.com/\n>       This patch series was integrated into seen via\n> https://github.com/git/git/commit/c645a5db002ded161115dc8f6c15a40acfdde2b2\n\n"},{"id":"557434","messageId":"CANHmUQSZqXtqXsiDQs+1unGcyEuaPhaF8__E_Cy4fWNqxapY5A@mail.gmail.com","threadId":"66766","inReplyTo":"CANHmUQSBs=Mq1Y1GTY6P9FtyCQz58bDWFgJPgwv4r5rLP3C1Bg@mail.gmail.com","subject":"[Outreachy] Project Proposal [v2] : Implement promisor remote fetch ordering","fromName":"Shashank S","fromEmail":"shashu8660@gmail.com","sentAt":"2026-11-04T12:27:39Z","receivedAt":"2026-11-04T12:27:39Z","isPatch":false,"sender":{"key":"shashu8660@gmail.com","avatar":null},"body":"Hello mentors and Git community,\n\nThis is version 2 of my 13-week project proposal for the \"Implement\npromisor remote fetch ordering\" project for the December 2026\nOutreachy internship.\n\nChanges since v1:\n- Fixed a typo in Kaartic Sivaraam's email address in the CC line.\n- Fixed broken/merged URLs in the \"Contributions to the Git Community\" section.\n- Included the full text of the proposal inline below for easier\nreading on the mailing list.\n\nI would appreciate any feedback from the community.\n\nPersonal Information\n====================\nFull Name: Shashank S Mogaveera\nEmail: shashu8660@gmail.com\nGitHub: https://github.com/shashu8660\nLocation: Kundapur, Karnataka, India (IST, UTC+5:30)\n\nAbout Me\n========\nI am Shashank, a software developer with a strong passion for C\nprogramming, system architecture, and network protocols. My journey\ninto open-source development began with a desire to understand how\nmassive, distributed systems operate under the hood.\n\nDuring this Outreachy contribution phase, I initially focused on Git's\ncore libification and option-parsing APIs. However, my true interest\nlies in network optimization. Diving into Git's GIT_TRACE2 engine to\nmap out how partial clones communicate with promisor remotes convinced\nme that the \"Implement promisor remote fetch ordering\" project is\nexactly where I want to focus my 13-week internship.\n\nPast Experience with Git\n========================\nI have been using Git extensively for version control in my personal\nprojects. This contribution period was my first time engaging directly\nwith a mailing list-based open-source community.\n\nLearning to use git send-email and GitGitGadget to format patches,\nmanage versioned rerolls, and incorporate maintainer feedback has been\na massive learning curve, but a highly rewarding one. I learned the\nimportance of atomic commits, clean commit messages, and the strict\nrules around not ignoring Git's exit codes in shell scripts.\n\nContributions to the Git Community\n==================================\n\n1. t0081: modernize the code testing whether a file exists\n   Link: https://lore.kernel.org/git/pull.2254.git.1791962806807.gitgitgadget@gmail.com/\n   Status: Merged to master.\n   Commit: https://github.com/git/git/commit/e1bb515788e48d500c9d4e36f13c66c4daddd3d4\n\n2. t2403: modernize test for directory existence\n   Link: https://lore.kernel.org/git/pull.2259.git.1792125111461.gitgitgadget@gmail.com/\n   Status: Merged to seen.\n   Commit: https://github.com/git/git/commit/c645a5db002ded161115dc8f6c15a40acfdde2b2\n\n3.  prune-packed: remove USE_THE_REPOSITORY_VARIABLE\n   Status: Reviewed and marked ready for integration by Patrick Steinhardt.\n   Description: I refactored the C file to pass a struct repository *r\npointer through a void *cb_data callback API, successfully removing\nthe reliance on Git's global state variables.\n\n4.  test-chmtime: use parse_options() to parse command-line flags\n   Status: v2 submitted.\n   Description: I ported ad-hoc command-line argument scanning to\nGit's official C-level parse_options() API, handling edge cases for\nrelative time offsets, and added t0082-test-chmtime.sh.\n\nProject Overview: Promisor Remote Fetch Ordering\n================================================\nWhen a Git repository is configured as a partial clone with multiple\npromisor remotes, there is currently no defined mechanism to specify\nthe order in which these remotes should be queried for missing\nobjects.\n\nDifferent remotes have vastly different performance characteristics\nand bandwidth costs. Currently, Git relies on a hardcoded fallback\nsystem rather than deterministic priority. This project aims to\nimplement a flexible fetch ordering mechanism by introducing a\nclient-side configuration list (promisor.fetchOrder) and a server-side\nadvertisement extension via Git Protocol v2, allowing servers to\nbroadcast their preferred fetch order.\n\nPhase 0: Baseline & Trace2 Playground Verification\n==================================================\nBefore designing the protocol enhancements, I established a verifiable\nbaseline by building a local partial clone playground with multiple\ndummy promisor remotes (server-A and server-B).\n\nTo prove the telemetry, I forced a lazy fetch by requesting a missing\nobject and captured the transaction using GIT_TRACE2_EVENT.\n* Verification: While the promisor.fetch_count=1 data event simply\nconfirmed a lazy fetch was triggered, extracting the sequential\nchild_start subprocess events (e.g., [\"git\",\"fetch\",\"cache-a\"...])\nprovided the definitive proof of Git's remote routing order.\n\nThe Current Baseline (Ordering Rules): Git currently lacks a\ndeterministic, user-configurable fetch priority system. Based on my\ntrace testing, t5710, and the logic in promisor-remote.c, the current\nhardcoded fallback hierarchy is:\n1. Git first tries \"accepted\" remotes (server-advertised remotes that\nwere provided to the client during a previous operation).\n2. It then iterates through ordinary configured remotes in the order\nthey are stored/parsed.\n3. The remote configured via extensions.partialClone (usually origin)\nis treated strictly as a fallback and checked last.\n\nIf a remote fails, Git moves to the next available promisor remote in\nthis hierarchy until the missing object is found or all remotes are\nexhausted.\n\nInternship Plan and 13-Week Timeline\n====================================\nThe internship runs from 7 December 2026 to 8 March 2027.\n\nWeeks 1–2 (Dec 7 – Dec 20): Phase 1 - Visibility and Baseline\n- Goal: Document and lock in Git's current behavior to act as a safety net.\n- Tasks: Submit a docs-only upstream patch defining the current\nfallback rules (accepted before configured, extensions.partialClone\nlast, fallback on failure). Develop automated tests utilizing\nGIT_TRACE2 to definitively lock in and prove the current sequential\nfetch order.\n\nWeeks 3–5 (Dec 21 – Jan 10): Phase 2 - Client-Side Ordering\n- Goal: Implement local configuration for promisor remote priorities.\n- Tasks: Introduce the promisor.fetchOrder configuration list. A list\nis preferred over per-remote integers as it composes cleanly across\nconfig files. Refactor internal sorting logic in promisor-remote.c to\nreorder remotes based on this list before initiating lazy fetches.\nImplement edge-case handling for unlisted remotes and preserve the\nextensions.partialClone-last fallback rule.\n\nWeeks 6–9 (Jan 11 – Feb 7): Phase 3 - Server-Advertised Order\n- Goal: Extend Protocol v2 to allow servers to broadcast their\npreferred priority.\n- Tasks: Draft an RFC proposing the protocol v2 explicit priority=<n>\nfields. Implement server-side advertisement gated by a new\npromisor.sendFields configuration. Implement the client-side parser,\nstrictly adhering to the \"ignore unknown fields\" rule to maintain\nbackward compatibility.\n\nWeeks 10–12 (Feb 8 – Feb 28): Phase 4 - Upstreaming & Precedence\n- Goal: Secure mailing list approval and resolve precedence rules.\n- Tasks: Settle precedence conflicts (Recommendation: local client\nconfig maintains absolute authority, while the server's advertised\norder sorts unranked remotes). Split Phase 2 and Phase 3 into a clean,\nreviewable patch series. Route through at least two rounds of mailing\nlist review.\n\nWeek 13 (Mar 1 – Mar 8): Polish & Stretch Goals\n- Goal: Finalize documentation and explore dynamic caching.\n- Tasks: Write final release notes and user-facing documentation.\nStretch Goal: Implement runtime memory of failed remotes within a\nsingle process to skip them on subsequent lazy fetches to reduce\nlatency. Submit final Outreachy report.\n\nAvailability\n============\nI can commit 40 hours a week to the project during the internship. I\nam based in India (IST, UTC+5:30) and can adjust my hours for\nsynchronous calls, pair programming, and mailing list reviews to\noverlap with my mentors' timezones.\n\nBlogging\n========\nI will document my technical journey , posting weekly updates on the\nC-level challenges I face, how I navigate network tracing, and the\nfeedback I receive from the Git community. I will share each post on\nthe mailing list.\n\nAfter the Internship\n====================\nAfter the internship, I intend to remain an active contributor to the\nGit core project. Having touched the libification, option parsing, and\nnetwork protocol subsystems during my application, I want to continue\nbridging these areas—specifically helping remove the remaining\nUSE_THE_REPOSITORY_VARIABLE macros from network-facing C files like\npromisor-remote.c.\n\nAppreciation\n============\nI want to express my gratitude to Christian Couder, Usman Akinyemi,\nSiddharth Asthana, Kaartic Sivaraam, Patrick Steinhardt, and Junio C\nHamano. Your patience in reviewing my early patches and helping me\nunderstand the git send-email workflow has been incredible. Thank you\nfor making this community so welcoming.\n\nThank you\n\nShashank S Mogaveera\n\n"},{"id":"557517","messageId":"CAPSxiM-bqtG7-qZa3mmiBUNaWrnKF-U6XkEJ_SUk-x5dZryn1g@mail.gmail.com","threadId":"66766","inReplyTo":"CANHmUQSZqXtqXsiDQs+1unGcyEuaPhaF8__E_Cy4fWNqxapY5A@mail.gmail.com","subject":"Re: [Outreachy] Project Proposal [v2] : Implement promisor remote fetch ordering","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2026-11-05T00:03:46Z","receivedAt":"2026-11-05T00:03:46Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"> Thank you\n>\n> Shashank S Mogaveera\n\nThanks for your proposal, do not forget to submit your application\non the Outreachy website.\n\nThanks.\n\n"}]}