{"thread":{"id":"65103","subject":"[GSoC] [Proposal]: Implement promisor remote fetch ordering","startedAt":"2026-02-28T23:27:34Z","lastAt":"2026-03-31T10:10:52Z","messageCount":12,"participants":["Abraham Samuel Adekunle","Christian Couder","Samuel Abraham"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"537418","messageId":"aaN5OPgoGANYlabu@Adekunles-MacBook-Air.local","threadId":"65103","inReplyTo":null,"subject":"[GSoC] [Proposal]: Implement promisor remote fetch ordering","fromName":"Abraham Samuel Adekunle","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-02-28T23:27:38Z","receivedAt":"2026-02-28T23:27:34Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"Hello,\nThis is my proposal for the project\n\"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n\nPersonal Bio:\n=============\nFull Name: Abraham Samuel Adekunle\nEmail: abrahamadekunle50@gmail.com\nGitHub: https://github.com/devdekunle\nPronouns: he/him\n\nAbout Me:\n=========\nMy name is Abraham Samuel Adekunle. I love to code, read and I am a\nharworker. In my free time I love to play games and listen to soothing\nmusic and well, also shifting into diffuse thinking to gain a new\nperspective of whatever challenge I am trying to solve.\n\nI am very curious so I really love to learn as its a never ending\njourney, and I believe in the power of \"yet\".\nI can understand anything, it is only a matter of time and effort.\nI love to figure out things and be part of a community\nwhere we can share experiences and support each other in growth.\n\nPast Experience with Git:\n=========================\nI first learnt about Git during my ALX Software Engineering days in\n2022, it proved challenging at first understanding what was going on\nand a git merge conflict was always a scary experience.\nNow I feel elated actually contributing to this renowned project.\n\nContributions to the Git Community:\n====================================\nMy first contribution to the Git community was during the contribution\nphase of the December 2024 Outreachy contribution phase where I first\nlearned to send patches and had my first interactions with the Git code\nbase. I did not make it through then but it was an opportunity to try\nagain.\n\nContributions to other Communities:\n===================================\nI have contributed very sparingly to the Systemd project and also\nthe Linux Kernel.\n\nMicroproject:\n=============\nLink: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/\nBranch: aa/add-p-previous-decisions\nStatus: Merged to master\nCommit ID: 8cafc305e22a59efb92472d4132616e24d3184c6\nDescription: \"git add -p\" and friends notes what the current status\n\t of the hunk being shown is\n\nOther Contributions:\n====================\n1.\nLink: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/\nBranch: aa/add-p-no-auto-advance\nStatus: Merged to next\nDescription: \"git add -p\" learned a new mode that allows the user to\n\t revisit a file that was already dealt with\n\n2.\nLink: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/\nStatus: Stalled\nDescription: the patch attempts to remove the use of the_repository\n\t global variable in some builtins\n\nProject Overview and Objective:\n===============================\nI have always wondered what happens in the background when I see these\ndetails on my screen in a \"git fetch\" process.\n\n\tremote: Enumerating objects: 57, done.\n\tremote: Counting objects: 100% (57/57), done.\n\tremote: Compressing objects: 100% (12/12), done.\n\tReceiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done.\n\tResolving deltas: 100% (21/21), done.\n\tremote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30\n\tFrom https://example.com/me/repo\n\t1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz\n\nAnd when I saw this project from the list of projects listed,\nI was endeared to it as it is an opportunity to work in an area of the\nthat Git code base that will satisfy my curiousity while also being\nmentored by very best and most experienced Engineers there is.\n\nWhen a Git repository is configured with multiple promisor remotes,\nthere is currently no mechanism to specify or optimize the order in\nwhich these remotes should be queried when fetching missing objects.\nDifferent remotes may have different performance characteristics\nsuch as characteristics, cost, or reliability which makes the\nfetching order an important consideration.\n\nThe project aims to implement a fetch ordering mechanism for multiple\npromisor remotes by designing a flexible system that allows a server\nto dictate their preferred order to the client to ensure performance\nand cost management.\n\nReview of Previous Work:\n========================\nThe project is part of the Large Object Promisor \"LOP\" effort\ndocumented in Documentatio/technical/large-object-promisor.adoc.\n\nIn a bid to better handle large objects, the promisor-remote\ncapability was added to the Git protocol v2, as documented in\nthe promisor-remote section of Documentation/gitprotocol-v2.adoc,\nwhich enables a protocol negotiation so that the server can advertise\none or more promisor remotes and so that the client and server can\ndiscuss if the client could directly use a promisor remote the server\nis advertising and if an agreement is reached, the client would be\nable to get the large blobs directly from the promisor remote without\nthe server acting as a relay between the client and the promisor remote when\nfetching missing large blobs.\n\nThe ground work for adding this capability to the v2 protocol was\nstarted by Christian Couder in [1], where if the \"promisor.advertise\"\nconfig is set to true, the server can then propagate its promisor remote\nconfigurations to the client over the v2 protocol during the negotiation\nin the form\n\n\t\"promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2\"\n\nThe client can then choose to accept some promisor remotes the server\nis advertising using the \"All\", \"None\", \"KnownName\" or \"KnownUrl\"\nconfigurations as values for the \"promisor.acceptfromServer\" config option.\n\nIn [2], Christian added the option for a server to advertise more\nfields after the \"name\" and \"url\", such as \"token\" and\n\"partialCloneFilter\" for the client to use this additional information\nin deciding the remotes to use as its promisor remotes by comparing it\nwith its local config information.\n\nThis was implemented by adding the \"promisor.sendFields\" and \"promisor.checkFields\"\nconfig values to the server and client respectively.\nFor example, if \"promisor.sendFields\" is set to \"partialCloneFilter\", and the\nserver has the remote configured like so:\n[remote \"foo\"]\n\turl = https://pr.test\n\tpartialCloneFilter = blob:none\n\ttoken = \"fake\"\nthen\n\"name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake\"\nwill be advertised by the server to the client who can then decide,\nusing the \"promisor.checkFields\" setting, to check if the passed field\nmatches certain conditions before deciding to use it.\n\nThis work by Christian is very crucial to this project as I will take\nadvantage of this and enable the advertisement of a \"priority\" field\nthat the server can use to communicate with the client in deciding to\nuse the server recommended fetch order or not.\n\nin [3] Christian also implemented the option \"promisor.storeFields\" which\nallowed the value of the configuration to be saved in the client's\nconfiguration file for use at a later time.\nAs above, this option will also prove important when the server advertises\nthe \"priority\" field as it will allow the client decided to store it in its\nconfig settings for that promisor remote, for later use when fetching\nthe remaining blobs from the promisor remotes.\n\nHigh Level Approach to Project Execution:\n=========================================\n1. Server Side Advertisement:\n-----------------------------\nAs the server knows about the promisor remotes which hold the\nlarge object blobs, it could recommend the order in which these remotes\ncould be queried by the client using a \"priority=\" field of the\npromisor-remote capability in the Git v2 protocol, where could\nbe an integer between 1 and 65535, where the smallest integer indicates\nhighest priority.\n\nThis will be an optional feature which will be enabled by the server\nif it wants to recommend ordered fetching to the client via\nthe \"promisor.sendFields=priority\" config option.\n\nHence if the server advertises promisor remotes prom1 and prom2,\nit could be of the form\n\t\"promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20\",\nif the server is configured as:\n[remote \"prom1\"]\n url = https://prom1.com\n\t priority = 10\n[remote \"prom2\"]\n\turl = https://prom2.com\n\tpriority = 20\n\nIf the \"promisor.sendFields\" values does not include the \"priority\"\nfield in its comma or space separated options, the field will not be\nadvertised in the promisor-remote capability.\n\n2. Client Side Parsing:\n-----------------------\nThe client can already use the \"promisor.acceptFromServer\" option to\ndecide which promisor remotes it will accept, so this new field\n\"priority\" might not be significant at all in the deciding phase but when\nfetching missing blobs from the accepted promisor remotes.\n\nInstead, if the client wants to use the server recommended \"priority\"\nlater when fetching the missing blob from the accepted promisor remotes,\nthe \"priority\" field will be added to the \"promisor.storeFields\" config\noptions so that the passed value can be saved to the client config.\nIf the client does not enable this option in the config, the \"priority\"\nfield will not be saved in the local config and the fetching order will\ndefault to the local config order.\n\nA new config \"promisor.honorServerFetchOrder\" will be implemented\non the client side to determine if the client will use the recommended\nserver advertised promisor remote fetching order or not.\nThis config can only be enabled if \"promsior.acceptFromServer\" is not\n\"None\".\n\nThe options for this config value will be [true|false|local-first] where\n\"false\" (default) ignores server priority and will rely on the current\nconfig order.\n\"true\" sorts candidate advertised remotes by priority in ascending\norder (smallest tried first).\n\"local-first\" will try remotes in local .git/config first in the order\nthe promisors are placed in the config file and then\nserver advertised ones ordered by priority, if the object has not been\nfound by now. This last values makes me feel somehow as all objects\ncould have been fetched already but I am just stating my thought process.\n\nProposed Project Execution Timeline:\n====================================\n\n1. Study code base to understand promisor-remote and fetch mechanism (May 1 - 14, 2026):\n -------------------------------------------------------------------------------------\n- Study the code base to understand how the client and server\n communicate using the protocol when client contacts the server.\n- Study how Git currently handles fetching from multiple remotes.\n- Set up blog for posting once a week\n\n2. Community Bonding (May 1 - 24, 2026):\n----------------------------------------\n- Discuss design details with community and mentors\n- Understand safety, security constraints and design considerations.\n when implementing fetch ordering.\n- Read indepth the Documentations for promisor-remote, gitprotocol-v2,\n and other necessary documentations.\n- Post updates on my blog\n\n3. Review Existing Patches (May 25 - June 14, 2026):\n-------------------------------\n- Study Christian's patches in-depth to understand how a new field is\n added to the promisor remote of server, what conditions\n are used to ensure the data is of the right format, correctly passed from\n server to client, and correctly parsed and stored by client.\n- Understand the tests to see how these new features are tested\n- Post updates on my blog\n\n4. Allow a server to add the \"priority\" field to the promisor-remote capability (June 14 - June 21, 2026)\n-------------------------------------------------------------------------------\n- Discuss with mentors on the suggested approach\n- Allow the server to add the field \"priority\" to the promisor-remote\n capability when it is enabled in \"promisor.sendFields\".\n- Write tests to ensure proper implementation\n- Update documentation in Documenantation/config/promisor.adoc\n- Submit patch to mailing list for discussions and address reviews\n- Post updates on my blog\n\n5. Allow Client to Decide to use the field (June 21 - 31, 2026):\n-----------------------------------------------------------------\n- Discuss strategy with mentors\n- Allow the server to store the \"priority\" in its .git/config if it\n accepts the promisor remotes and it is included in \"promisor.storeFields\"\n- Write unit tests to ensure proper implementations\n- Update documentation in Documenantation/config/promisor.adoc\n- Submit patches to mailing list for reviews and address feedbacks\n- Post updates on my blog\n\n6. Implement setting to decide fetching order: (July 1 - July 14, 2026):\n------------------------------------------------------------------------\n- Discuss with mentors on the approach and considerations for fetch order\n- Implement option \"promisor.honorServerOrder\" which will decide the\n order of fetching missing objects from the remote\n- Write unittests to test implementation\n- Update documentation in Documenantation/config/promisor.adoc\n- Submit patches for review and address reviews\n- Post updates on my blog\n\n7. Implement fetching based on the selected order (July 15 - August 15, 2026):\n------------------------------------------------------------------------------\n- Implement the ordered fetching for missing objects based on the cient's\n configuration in 6 above.\n- Write unit tests to ensure the order was properly followed\n- Submit to mailing list and be involved in the review process\n- Post updates on my blog\n\n8. Final Report on Project (August 15 - 24, 2026):\n--------------------------------------------------\n- Document any final report in my blog with details of my experience\n- Finalize any pending tasks\n\nAvailability:\n=============\nI will be able to give 30 hours a week to make the project a success\n\nPost GSoC\n=========\n\nThough this is not my first contribution to Git, as I have contributed\nvery lightly to the codebase before, I am committed to\ncontinuously contributing to Git and become a part of the next set\nof contributors to champion the continuous development of Git.\n\nAppreciation\n============\nTo Junio C Hamano, Phillip Wood, and everyone who helped with my patches.\nI really appreciate your guidance, patience and direction while\nreviewing and my patches.\n\nThanks\n\nReferences\n===========\n1. https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/\n2. https://lore.kernel.org/git/20250908053056.956907-1-christian.couder@gmail.com/\n3. https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/\n"},{"id":"537650","messageId":"CAP8UFD1kzuP8sYKzTJkvf08OazrMzESQ+qZNW8=Qss3DDw=OeA@mail.gmail.com","threadId":"65103","inReplyTo":"aaN5OPgoGANYlabu@Adekunles-MacBook-Air.local","subject":"Re: [GSoC] [Proposal]: Implement promisor remote fetch ordering","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-03T09:27:32Z","receivedAt":"2026-03-03T09:27:45Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Sun, Mar 1, 2026 at 12:27 AM Abraham Samuel Adekunle\n wrote:\n>\n> Hello,\n> This is my proposal for the project\n> \"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n\nThanks for being interested in Git and this project in particular.\n\n> Personal Bio:\n> =============\n> Full Name: Abraham Samuel Adekunle\n> Email: abrahamadekunle50@gmail.com\n> GitHub: https://github.com/devdekunle\n> Pronouns: he/him\n>\n> About Me:\n> =========\n> My name is Abraham Samuel Adekunle. I love to code, read and I am a\n> harworker. In my free time I love to play games and listen to soothing\n\nI guess: s/harworker/hardworker/\n\n> music and well, also shifting into diffuse thinking to gain a new\n> perspective of whatever challenge I am trying to solve.\n\n[...]\n\n> Contributions to the Git Community:\n> ====================================\n> My first contribution to the Git community was during the contribution\n> phase of the December 2024 Outreachy contribution phase where I first\n> learned to send patches and had my first interactions with the Git code\n> base. I did not make it through then but it was an opportunity to try\n> again.\n\nNice that you are trying again.\n\n> Contributions to other Communities:\n> ===================================\n> I have contributed very sparingly to the Systemd project and also\n> the Linux Kernel.\n>\n> Microproject:\n> =============\n> Link: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/\n> Branch: aa/add-p-previous-decisions\n> Status: Merged to master\n> Commit ID: 8cafc305e22a59efb92472d4132616e24d3184c6\n> Description: \"git add -p\" and friends notes what the current status\n> of the hunk being shown is\n>\n> Other Contributions:\n> ====================\n> 1.\n> Link: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/\n> Branch: aa/add-p-no-auto-advance\n> Status: Merged to next\n> Description: \"git add -p\" learned a new mode that allows the user to\n> revisit a file that was already dealt with\n>\n> 2.\n> Link: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/\n> Status: Stalled\n> Description: the patch attempts to remove the use of the_repository\n> global variable in some builtins\n\nIt looks like you also have 2 contributions merged from October 2024\n(when you applied for Outreachy). You can mention them too.\n\n> Project Overview and Objective:\n> ===============================\n> I have always wondered what happens in the background when I see these\n> details on my screen in a \"git fetch\" process.\n>\n> remote: Enumerating objects: 57, done.\n> remote: Counting objects: 100% (57/57), done.\n> remote: Compressing objects: 100% (12/12), done.\n> Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done.\n> Resolving deltas: 100% (21/21), done.\n> remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30\n> From https://example.com/me/repo\n> 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz\n>\n> And when I saw this project from the list of projects listed,\n> I was endeared to it as it is an opportunity to work in an area of the\n> that Git code base that will satisfy my curiousity while also being\n\ns/curiousity/curiosity/\n\n> mentored by very best and most experienced Engineers there is.\n>\n> When a Git repository is configured with multiple promisor remotes,\n> there is currently no mechanism to specify or optimize the order in\n> which these remotes should be queried when fetching missing objects.\n> Different remotes may have different performance characteristics\n> such as characteristics, cost, or reliability which makes the\n> fetching order an important consideration.\n\nIn which order are they currently queried?\n\n> The project aims to implement a fetch ordering mechanism for multiple\n> promisor remotes by designing a flexible system that allows a server\n> to dictate their preferred order to the client to ensure performance\n> and cost management.\n\nA part of the whole system that allows servers to advertise\ninformation already exists and should be reused.\n\nWe use \"advertise\" instead of \"dictate\" because the client should be\nable to decide.\n\n> Review of Previous Work:\n> ========================\n> The project is part of the Large Object Promisor \"LOP\" effort\n> documented in Documentatio/technical/large-object-promisor.adoc.\n\ns/Documentatio/Documentation/\ns/large-object-promisor/large-object-promisors/\n\n> In a bid to better handle large objects, the promisor-remote\n> capability was added to the Git protocol v2, as documented in\n> the promisor-remote section of Documentation/gitprotocol-v2.adoc,\n> which enables a protocol negotiation so that the server can advertise\n> one or more promisor remotes and so that the client and server can\n> discuss if the client could directly use a promisor remote the server\n> is advertising and if an agreement is reached, the client would be\n> able to get the large blobs directly from the promisor remote without\n> the server acting as a relay between the client and the promisor remote when\n> fetching missing large blobs.\n>\n> The ground work for adding this capability to the v2 protocol was\n> started by Christian Couder in [1], where if the \"promisor.advertise\"\n> config is set to true, the server can then propagate its promisor remote\n> configurations to the client over the v2 protocol during the negotiation\n> in the form\n>\n> \"promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2\"\n>\n> The client can then choose to accept some promisor remotes the server\n> is advertising using the \"All\", \"None\", \"KnownName\" or \"KnownUrl\"\n> configurations as values for the \"promisor.acceptfromServer\" config option.\n>\n> In [2], Christian added the option for a server to advertise more\n> fields after the \"name\" and \"url\", such as \"token\" and\n> \"partialCloneFilter\" for the client to use this additional information\n> in deciding the remotes to use as its promisor remotes by comparing it\n> with its local config information.\n>\n> This was implemented by adding the \"promisor.sendFields\" and \"promisor.checkFields\"\n> config values to the server and client respectively.\n> For example, if \"promisor.sendFields\" is set to \"partialCloneFilter\", and the\n> server has the remote configured like so:\n> [remote \"foo\"]\n> url = https://pr.test\n> partialCloneFilter = blob:none\n> token = \"fake\"\n> then\n> \"name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake\"\n> will be advertised by the server to the client who can then decide,\n> using the \"promisor.checkFields\" setting, to check if the passed field\n> matches certain conditions before deciding to use it.\n>\n> This work by Christian is very crucial to this project as I will take\n> advantage of this and enable the advertisement of a \"priority\" field\n> that the server can use to communicate with the client in deciding to\n> use the server recommended fetch order or not.\n>\n> in [3] Christian also implemented the option \"promisor.storeFields\" which\n> allowed the value of the configuration to be saved in the client's\n> configuration file for use at a later time.\n> As above, this option will also prove important when the server advertises\n> the \"priority\" field as it will allow the client decided to store it in its\n> config settings for that promisor remote, for later use when fetching\n> the remaining blobs from the promisor remotes.\n\nYeah, this is about allowing the server to advertise priority\ninformation, and the client to accept it or not, but this doesn't talk\nmuch about how this information will be used to actually change the\nfetch order.\n\nIt would be nice if this could talk about which order is currently\nused. You might want to take a look at\nDocumentation/technical/partial-clone.adoc, especially the \"Using many\npromisor remotes\" section.\n\n> High Level Approach to Project Execution:\n> =========================================\n> 1. Server Side Advertisement:\n> -----------------------------\n> As the server knows about the promisor remotes which hold the\n> large object blobs,\n\nFirst I would say \"large blob objects\" or just \"large blobs\" instead\nof \"large object blobs\" if I wanted to talk about them.\n\nThen it's true that the \"promisor-remote\" capability in protocol v2\nwas developed especially to help with large blobs and the LOP effort,\nbut this GSoC project could be useful for any partial clone that uses\nmultiple promisor remotes. So you could talk about \"objects\", not just\n\"large blobs\".\n\n> it could recommend the order in which these remotes\n> could be queried by the client using a \"priority=\" field of the\n> promisor-remote capability in the Git v2 protocol, where could\n> be an integer between 1 and 65535, where the smallest integer indicates\n> highest priority.\n>\n> This will be an optional feature which will be enabled by the server\n> if it wants to recommend ordered fetching to the client via\n> the \"promisor.sendFields=priority\" config option.\n>\n> Hence if the server advertises promisor remotes prom1 and prom2,\n> it could be of the form\n> \"promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20\",\n> if the server is configured as:\n> [remote \"prom1\"]\n> url = https://prom1.com\n> priority = 10\n> [remote \"prom2\"]\n> url = https://prom2.com\n> priority = 20\n>\n> If the \"promisor.sendFields\" values does not include the \"priority\"\n> field in its comma or space separated options, the field will not be\n> advertised in the promisor-remote capability.\n\nThe issue is that right now \"priority = 10\" or \"priority = 20\" if they\nwere configured would change nothing in the order used to fetch from\npromisor remotes. So the first thing to do (before having the server\nsend that and the client use it or not) is to actually introduce the\n`remote..priority` config option and make it change the fetch\norder. When that works, it makes sense to allow the server to\nadvertise it, and the client to accept it or not from the server.\n\n> 2. Client Side Parsing:\n> -----------------------\n> The client can already use the \"promisor.acceptFromServer\" option to\n> decide which promisor remotes it will accept, so this new field\n> \"priority\" might not be significant at all in the deciding phase but when\n> fetching missing blobs from the accepted promisor remotes.\n\nIf that's what you mean, I agree that the priority advertised by a\nserver for a promisor remote is not likely to be a (good) criteria on\nthe client side to help decide if the client accepts to use the\npromisor remote or not. You might want to reword the above paragraph\nthough as it's not easy to understand.\n\n> Instead, if the client wants to use the server recommended \"priority\"\n> later when fetching the missing blob from the accepted promisor remotes,\n> the \"priority\" field will be added to the \"promisor.storeFields\" config\n> options so that the passed value can be saved to the client config.\n\nYeah, that's the most likely way the client would use it.\n\n> If the client does not enable this option in the config, the \"priority\"\n> field will not be saved in the local config and the fetching order will\n> default to the local config order.\n\nRight.\n\n> A new config \"promisor.honorServerFetchOrder\" will be implemented\n> on the client side to determine if the client will use the recommended\n> server advertised promisor remote fetching order or not.\n\nI don't think this is necessary. If the client doesn't want to use the\npriority advertised by the server, it just needs to not add \"priority\"\nto the \"promisor.storeFields\" config variable.\n\n> This config can only be enabled if \"promsior.acceptFromServer\" is not\n> \"None\".\n>\n> The options for this config value will be [true|false|local-first] where\n> \"false\" (default) ignores server priority and will rely on the current\n> config order.\n> \"true\" sorts candidate advertised remotes by priority in ascending\n> order (smallest tried first).\n> \"local-first\" will try remotes in local .git/config first in the order\n> the promisors are placed in the config file and then\n> server advertised ones ordered by priority, if the object has not been\n> found by now. This last values makes me feel somehow as all objects\n\ns/values/value/\n\n> could have been fetched already but I am just stating my thought process.\n\nI think we will likely not need something like this. The 3 different\npossibilities could be configured this way:\n\n- to rely on the order advertised by the server: just add \"priority\"\nto \"promisor.storeFields\"\n- to rely on local \"priority\" config: just add \"priority = XXX\" to\nsome/all \"remote.\"\n- to rely on the default order: add nothing\n\n> Proposed Project Execution Timeline:\n> ====================================\n\nThis needs to take into account that the first step should be to\nactually introduce the `remote..priority` config option and make\nit change the fetch order.\n\nThanks.\n"},{"id":"537656","messageId":"CADYq+fYf0+CYSs8j54WhhrE_=k+dtvznwWTcpX24f6wt4nL0ow@mail.gmail.com","threadId":"65103","inReplyTo":"CAP8UFD1kzuP8sYKzTJkvf08OazrMzESQ+qZNW8=Qss3DDw=OeA@mail.gmail.com","subject":"Re: [GSoC] [Proposal]: Implement promisor remote fetch ordering","fromName":"Samuel Abraham","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-03T12:08:57Z","receivedAt":"2026-03-03T12:08:58Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"On Tue, Mar 3, 2026 at 10:27 AM Christian Couder\n wrote:\n>\n> Hi,\n>\n> On Sun, Mar 1, 2026 at 12:27 AM Abraham Samuel Adekunle\n> wrote:\n> >\n> > Hello,\n> > This is my proposal for the project\n> > \"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n>\n> Thanks for being interested in Git and this project in particular.\n\nThank you.\n\n>\n> > Personal Bio:\n> > =============\n> > Full Name: Abraham Samuel Adekunle\n> > Email: abrahamadekunle50@gmail.com\n> > GitHub: https://github.com/devdekunle\n> > Pronouns: he/him\n> >\n> > About Me:\n> > =========\n> > My name is Abraham Samuel Adekunle. I love to code, read and I am a\n> > harworker. In my free time I love to play games and listen to soothing\n>\n> I guess: s/harworker/hardworker/\n\nOkay I will fix it\n\n>\n> > music and well, also shifting into diffuse thinking to gain a new\n> > perspective of whatever challenge I am trying to solve.\n>\n> [...]\n>\n> > Contributions to the Git Community:\n> > ====================================\n> > My first contribution to the Git community was during the contribution\n> > phase of the December 2024 Outreachy contribution phase where I first\n> > learned to send patches and had my first interactions with the Git code\n> > base. I did not make it through then but it was an opportunity to try\n> > again.\n>\n> Nice that you are trying again.\n\nThank you :)\n\n>\n> > Contributions to other Communities:\n> > ===================================\n> > I have contributed very sparingly to the Systemd project and also\n> > the Linux Kernel.\n> >\n> > Microproject:\n> > =============\n> > Link: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/\n> > Branch: aa/add-p-previous-decisions\n> > Status: Merged to master\n> > Commit ID: 8cafc305e22a59efb92472d4132616e24d3184c6\n> > Description: \"git add -p\" and friends notes what the current status\n> > of the hunk being shown is\n> >\n> > Other Contributions:\n> > ====================\n> > 1.\n> > Link: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/\n> > Branch: aa/add-p-no-auto-advance\n> > Status: Merged to next\n> > Description: \"git add -p\" learned a new mode that allows the user to\n> > revisit a file that was already dealt with\n> >\n> > 2.\n> > Link: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/\n> > Status: Stalled\n> > Description: the patch attempts to remove the use of the_repository\n> > global variable in some builtins\n>\n> It looks like you also have 2 contributions merged from October 2024\n> (when you applied for Outreachy). You can mention them too.\n\nOkay I will do that.\n\n>\n> > Project Overview and Objective:\n> > ===============================\n> > I have always wondered what happens in the background when I see these\n> > details on my screen in a \"git fetch\" process.\n> >\n> > remote: Enumerating objects: 57, done.\n> > remote: Counting objects: 100% (57/57), done.\n> > remote: Compressing objects: 100% (12/12), done.\n> > Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done.\n> > Resolving deltas: 100% (21/21), done.\n> > remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30\n> > From https://example.com/me/repo\n> > 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz\n> >\n> > And when I saw this project from the list of projects listed,\n> > I was endeared to it as it is an opportunity to work in an area of the\n> > that Git code base that will satisfy my curiousity while also being\n>\n> s/curiousity/curiosity/\n\nThanks\n\n>\n> > mentored by very best and most experienced Engineers there is.\n> >\n> > When a Git repository is configured with multiple promisor remotes,\n> > there is currently no mechanism to specify or optimize the order in\n> > which these remotes should be queried when fetching missing objects.\n> > Different remotes may have different performance characteristics\n> > such as characteristics, cost, or reliability which makes the\n> > fetching order an important consideration.\n>\n> In which order are they currently queried?\n\nIn the order they appear in the config file, with promisor remote\nconfigured with the\nextensions.partialClone (most likely \"origin\") bring the last one tried.\n\n>\n> > The project aims to implement a fetch ordering mechanism for multiple\n> > promisor remotes by designing a flexible system that allows a server\n> > to dictate their preferred order to the client to ensure performance\n> > and cost management.\n>\n> A part of the whole system that allows servers to advertise\n> information already exists and should be reused.\n>\n> We use \"advertise\" instead of \"dictate\" because the client should be\n> able to decide.\n\nI will reword it. Thanks\n\n>\n> > Review of Previous Work:\n> > ========================\n> > The project is part of the Large Object Promisor \"LOP\" effort\n> > documented in Documentatio/technical/large-object-promisor.adoc.\n>\n> s/Documentatio/Documentation/\n> s/large-object-promisor/large-object-promisors/\n\nThank you\n\n>\n> > In a bid to better handle large objects, the promisor-remote\n> > capability was added to the Git protocol v2, as documented in\n> > the promisor-remote section of Documentation/gitprotocol-v2.adoc,\n> > which enables a protocol negotiation so that the server can advertise\n> > one or more promisor remotes and so that the client and server can\n> > discuss if the client could directly use a promisor remote the server\n> > is advertising and if an agreement is reached, the client would be\n> > able to get the large blobs directly from the promisor remote without\n> > the server acting as a relay between the client and the promisor remote when\n> > fetching missing large blobs.\n> >\n> > The ground work for adding this capability to the v2 protocol was\n> > started by Christian Couder in [1], where if the \"promisor.advertise\"\n> > config is set to true, the server can then propagate its promisor remote\n> > configurations to the client over the v2 protocol during the negotiation\n> > in the form\n> >\n> > \"promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2\"\n> >\n> > The client can then choose to accept some promisor remotes the server\n> > is advertising using the \"All\", \"None\", \"KnownName\" or \"KnownUrl\"\n> > configurations as values for the \"promisor.acceptfromServer\" config option.\n> >\n> > In [2], Christian added the option for a server to advertise more\n> > fields after the \"name\" and \"url\", such as \"token\" and\n> > \"partialCloneFilter\" for the client to use this additional information\n> > in deciding the remotes to use as its promisor remotes by comparing it\n> > with its local config information.\n> >\n> > This was implemented by adding the \"promisor.sendFields\" and \"promisor.checkFields\"\n> > config values to the server and client respectively.\n> > For example, if \"promisor.sendFields\" is set to \"partialCloneFilter\", and the\n> > server has the remote configured like so:\n> > [remote \"foo\"]\n> > url = https://pr.test\n> > partialCloneFilter = blob:none\n> > token = \"fake\"\n> > then\n> > \"name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake\"\n> > will be advertised by the server to the client who can then decide,\n> > using the \"promisor.checkFields\" setting, to check if the passed field\n> > matches certain conditions before deciding to use it.\n> >\n> > This work by Christian is very crucial to this project as I will take\n> > advantage of this and enable the advertisement of a \"priority\" field\n> > that the server can use to communicate with the client in deciding to\n> > use the server recommended fetch order or not.\n> >\n> > in [3] Christian also implemented the option \"promisor.storeFields\" which\n> > allowed the value of the configuration to be saved in the client's\n> > configuration file for use at a later time.\n> > As above, this option will also prove important when the server advertises\n> > the \"priority\" field as it will allow the client decided to store it in its\n> > config settings for that promisor remote, for later use when fetching\n> > the remaining blobs from the promisor remotes.\n>\n> Yeah, this is about allowing the server to advertise priority\n> information, and the client to accept it or not, but this doesn't talk\n> much about how this information will be used to actually change the\n> fetch order.\n>\n> It would be nice if this could talk about which order is currently\n> used. You might want to take a look at\n> Documentation/technical/partial-clone.adoc, especially the \"Using many\n> promisor remotes\" section.\n\nOkay thank you. I will add that to the v2.\n\n>\n> > High Level Approach to Project Execution:\n> > =========================================\n> > 1. Server Side Advertisement:\n> > -----------------------------\n> > As the server knows about the promisor remotes which hold the\n> > large object blobs,\n>\n> First I would say \"large blob objects\" or just \"large blobs\" instead\n> of \"large object blobs\" if I wanted to talk about them.\n\nOkay thank you\n\n>\n> Then it's true that the \"promisor-remote\" capability in protocol v2\n> was developed especially to help with large blobs and the LOP effort,\n> but this GSoC project could be useful for any partial clone that uses\n> multiple promisor remotes. So you could talk about \"objects\", not just\n> \"large blobs\".\n\nOkay Noted\n\n>\n> > it could recommend the order in which these remotes\n> > could be queried by the client using a \"priority=\" field of the\n> > promisor-remote capability in the Git v2 protocol, where could\n> > be an integer between 1 and 65535, where the smallest integer indicates\n> > highest priority.\n> >\n> > This will be an optional feature which will be enabled by the server\n> > if it wants to recommend ordered fetching to the client via\n> > the \"promisor.sendFields=priority\" config option.\n> >\n> > Hence if the server advertises promisor remotes prom1 and prom2,\n> > it could be of the form\n> > \"promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20\",\n> > if the server is configured as:\n> > [remote \"prom1\"]\n> > url = https://prom1.com\n> > priority = 10\n> > [remote \"prom2\"]\n> > url = https://prom2.com\n> > priority = 20\n> >\n> > If the \"promisor.sendFields\" values does not include the \"priority\"\n> > field in its comma or space separated options, the field will not be\n> > advertised in the promisor-remote capability.\n>\n> The issue is that right now \"priority = 10\" or \"priority = 20\" if they\n> were configured would change nothing in the order used to fetch from\n> promisor remotes. So the first thing to do (before having the server\n> send that and the client use it or not) is to actually introduce the\n> `remote..priority` config option and make it change the fetch\n> order. When that works, it makes sense to allow the server to\n> advertise it, and the client to accept it or not from the server.\n\nYes thank you.\nI will fix this in the v2\n\n>\n> > 2. Client Side Parsing:\n> > -----------------------\n> > The client can already use the \"promisor.acceptFromServer\" option to\n> > decide which promisor remotes it will accept, so this new field\n> > \"priority\" might not be significant at all in the deciding phase but when\n> > fetching missing blobs from the accepted promisor remotes.\n>\n> If that's what you mean, I agree that the priority advertised by a\n> server for a promisor remote is not likely to be a (good) criteria on\n> the client side to help decide if the client accepts to use the\n> promisor remote or not. You might want to reword the above paragraph\n> though as it's not easy to understand.\n\nOkay\n\n>\n> > Instead, if the client wants to use the server recommended \"priority\"\n> > later when fetching the missing blob from the accepted promisor remotes,\n> > the \"priority\" field will be added to the \"promisor.storeFields\" config\n> > options so that the passed value can be saved to the client config.\n>\n> Yeah, that's the most likely way the client would use it.\n>\n> > If the client does not enable this option in the config, the \"priority\"\n> > field will not be saved in the local config and the fetching order will\n> > default to the local config order.\n>\n> Right.\n>\n> > A new config \"promisor.honorServerFetchOrder\" will be implemented\n> > on the client side to determine if the client will use the recommended\n> > server advertised promisor remote fetching order or not.\n>\n> I don't think this is necessary. If the client doesn't want to use the\n> priority advertised by the server, it just needs to not add \"priority\"\n> to the \"promisor.storeFields\" config variable.\n\nOkay thank you\n\n>\n> > This config can only be enabled if \"promsior.acceptFromServer\" is not\n> > \"None\".\n> >\n> > The options for this config value will be [true|false|local-first] where\n> > \"false\" (default) ignores server priority and will rely on the current\n> > config order.\n> > \"true\" sorts candidate advertised remotes by priority in ascending\n> > order (smallest tried first).\n> > \"local-first\" will try remotes in local .git/config first in the order\n> > the promisors are placed in the config file and then\n> > server advertised ones ordered by priority, if the object has not been\n> > found by now. This last values makes me feel somehow as all objects\n>\n> s/values/value/\n>\n> > could have been fetched already but I am just stating my thought process.\n>\n> I think we will likely not need something like this. The 3 different\n> possibilities could be configured this way:\n>\n> - to rely on the order advertised by the server: just add \"priority\"\n> to \"promisor.storeFields\"\n> - to rely on local \"priority\" config: just add \"priority = XXX\" to\n> some/all \"remote.\"\n> - to rely on the default order: add nothing\n\nThank you for the guidance. I will fix all the changes in the v2\n\n>\n> > Proposed Project Execution Timeline:\n> > ====================================\n>\n> This needs to take into account that the first step should be to\n> actually introduce the `remote..priority` config option and make\n> it change the fetch order.\n\nYes\nThank you for the review.\n\nAbraham\n"},{"id":"537754","messageId":"aafga8AjpxagiEJt@Adekunles-MacBook-Air.local","threadId":"65103","inReplyTo":"aaN5OPgoGANYlabu@Adekunles-MacBook-Air.local","subject":"[GSoC] [Proposal v2]: Implement promisor remote fetch ordering","fromName":"Abraham Samuel Adekunle","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-04T07:35:49Z","receivedAt":"2026-03-04T07:35:42Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"Hello,\nThis is the second iteration of my proposal for the project\n\"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n\nPersonal Bio:\n=============\nFull Name: Abraham Samuel Adekunle\nEmail: abrahamadekunle50@gmail.com\nGitHub: https://github.com/devdekunle\nPronouns: he/him\n\nAbout Me:\n=========\nMy name is Abraham Samuel Adekunle. I love to code, read and I am a\nhard worker. In my free time I love to play games and listen to soothing\nmusic and well, also shift into diffuse thinking to gain a new\nperspective of whatever challenge I am trying to solve.\n\nI am very curious so I really love to learn as it's a never ending\njourney, and I believe in the power of \"yet\".\nI can understand anything, it is only a matter of time and effort.\nI love to figure out things and be part of a community\nwhere we can share experiences and support each other in growth.\n\nPast Experience with Git:\n=========================\nI first learnt about Git during my ALX Software Engineering days in\n2022, it proved challenging at first understanding what was going on\nand a git merge conflict was always a scary experience.\nNow I feel elated actually contributing to this renowned project.\n\nContributions to the Git Community:\n====================================\nMy first contribution to the Git community was during the contribution\nphase of the December 2024 Outreachy contribution phase where I first\nlearned to send patches and had my first interactions with the Git code\nbase. I did not make it through then but it was an opportunity to try\nagain.\n\nContributions to other Communities:\n===================================\nI have contributed very sparingly to the Systemd project and also\nthe Linux Kernel.\n\nMicroproject:\n=============\nLink: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/\nBranch: aa/add-p-previous-decisions\nStatus: Merged to master\nCommit ID: 8cafc305e22a59efb92472d4132616e24d3184c6\nDescription: \"git add -p\" and friends notes what the current status\n of the hunk being shown is\n\nOther Contributions:\n====================\n1.\nLink: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/\nBranch: aa/add-p-no-auto-advance\nStatus: Will merge to master\nDescription: \"git add -p\" learned a new mode that allows the user to\n revisit a file that was already dealt with\n\n2.\nLink: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/\nStatus: Stalled\nDescription: the patch attempts to remove the use of the_repository\n global variable in some builtins\n\n3.\nLink: https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@gmail.com/\nBranch: sa/notes-edit\nStatus: Merged to master\nDescription: Teach 'git notes add' and 'git notes append' a new '-e' flag,\n instructing them to open the note in $GIT_EDITOR before saving.\n\n4.\nLink: https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@gmail.com/\nBranch: aa/t7300-modernize\nStatus: Merged to master\nDescription: use test_path_* helper functions for error logging\n\nProject Overview and Objective:\n===============================\nI have always wondered what happens in the background when I see these\ndetails on my screen in a \"git fetch\" process.\n\n remote: Enumerating objects: 57, done.\n remote: Counting objects: 100% (57/57), done.\n remote: Compressing objects: 100% (12/12), done.\n Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done.\n Resolving deltas: 100% (21/21), done.\n remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30\n From https://example.com/me/repo\n 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz\n\nAnd when I saw this project from the list of projects listed,\nI was endeared to it as it is an opportunity to work in an area of the\nthat Git code base that will satisfy my curiosity while also being\nmentored by very best and most experienced Engineers there is.\n\nWhen a Git repository is configured with multiple promisor remotes,\nthere is currently no other mechanism to specify or optimize the order in\nwhich these remotes should be queried when fetching missing objects.\nDifferent remotes may have different performance characteristics\nsuch as characteristics, cost, or reliability which makes the\nfetching order an important consideration.\nCurrently, the promisor remotes are queried in the order in which they\nappear in the local .git/config.\n\nThe project aims to implement a fetch ordering mechanism for multiple\npromisor remotes that allows a client to be able to specify a fetching order,\na server to advertise an order to the client to ensure performance\nand cost management, and the client to decide to use the server advertised\norder or not, and default to the current order if no order is specified.\n\nReview of Previous Work:\n========================\nThe project is part of the Large Object Promisor \"LOP\" effort\ndocumented in Documentation/technical/large-object-promisors.adoc.\n\nIn a bid to better handle large objects, the promisor-remote\ncapability was added to the Git protocol v2, as documented in\nthe promisor-remote section of Documentation/gitprotocol-v2.adoc,\nwhich enables a protocol negotiation so that the server can advertise\none or more promisor remotes and so that the client and server can\ndiscuss if the client could directly use a promisor remote the server\nis advertising and if an agreement is reached, the client would be\nable to get the missing objects directly from the promisor remote without\nthe server acting as a relay between the client and the promisor remote when\nfetching missing objects.\n\nThe ground work for adding this capability to the v2 protocol was\nstarted by Christian Couder in [1], where if the \"promisor.advertise\"\nconfig is set to true, the server can then propagate its promisor remote\nconfigurations to the client over the v2 protocol during the negotiation\nin the form\n\n \"promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2\"\n\nThe client can then choose to accept some promisor remotes the server\nis advertising using the \"All\", \"None\", \"KnownName\" or \"KnownUrl\"\nconfigurations as values for the \"promisor.acceptfromServer\" config option.\n\nIn [2], Christian added the option for a server to advertise more\nfields after the \"name\" and \"url\", such as \"token\" and\n\"partialCloneFilter\" for the client to use this additional information\nin deciding the remotes to use as its promisor remotes by comparing it\nwith its local config information.\n\nThis was implemented by adding the \"promisor.sendFields\" and\n\"promisor.checkFields\" config values to the server and client respectively.\nFor example, if \"promisor.sendFields\" is set to \"partialCloneFilter\", and the\nserver has the remote configured like so:\n[remote \"foo\"]\n url = https://pr.test\n partialCloneFilter = blob:none\n token = \"fake\"\nthen\n\n\t\"name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake\"\nwill be advertised by the server to the client who can then decide,\nusing the \"promisor.checkFields\" setting, to check if the passed field\nmatches certain conditions before deciding to use it.\n\nThis work by Christian is very crucial to this project as I will take\nadvantage of this and enable the advertisement of a \"priority\" field\nthat the server can use to communicate with the client in deciding to\nuse the server recommended fetch order or not.\n\nin [3] Christian also implemented the option \"promisor.storeFields\" which\nallowed the value of the configuration to be saved in the client's\nconfiguration file for use at a later time.\nAs above, this option will also prove important when the server advertises\nthe \"priority\" field as it will allow the client decided to store it in its\nconfig settings for that promisor remote, for later use when fetching\nthe remaining blobs from the promisor remotes.\n\nAs documented in Documentation/technical/partial-clone.adoc, when using\nmultiple promisor remotes, currently, the promisor remotes are tried in the\norder in which they appear in the config file with the promisor remote\nconfigured with \"extension.partialClone\" being the last one tried.\n\nAs the goal of this project is to implement a fetch order when fetching\nthe missing objects, I would take advantage of the ground work\ndone by Christian by adding a \"priority\" field to the promisor-remote\ncapability when \"priority\" is added to the \"promisor.sendFields\" server\nconfig option, which indicates that the server is recommending the client\nto use the fetch order.\n\nIf the client chooses to use the server recommended fetch order, it can\nadd \"priority\" to the \"promisor.storeFields\" config option which will store\nthis values and query the promisor remotes in that order. If the client\nchoose to ignore this recommendation, it can simply choose not to store it and\ninstead use its own preferred order by setting the priority for some or all the\nremotes to its preferred value and this will query the objects in that order.\nNot using either of this order will query the promisor remotes in the current\ndefault order.\n\nHigh Level Approach to Project Execution:\n=========================================\n\n1. Introduce the `remote..priority` config option:\n======================================================\nAs said above, when fetching missing objects, the order in which the remotes\nare queried depends on the order in which they appear in the config file.\nTo make this flexible, I will introduce the `remote..priority` config option,\nwhich will allow the client to set its preferred fetch order to each promisor remote\nconfiguration, and then make it fetch based on this \"priority\" order.\nThe value of this option could be an integer between 1 and 65535, where the smallest\ninteger indicates highest priority.\n\nThis will allow a promisor remote be configured as follows\n\n\t[remote \"prom1\"]\n\t\turl = https://prom1.com\n\t\tpriority = 10\n\nTherefore when the client is configured with more than one promisor remote\nand the prority is set for each promisor remote as follows,\n\n\t[remote \"prom1\"]\n\t\turl = https://prom1.com\n\t\tpriority = 20\n\t[remote \"prom2\"]\n\t\turl = https://prom2.com\n\t\tpriority = 10,\n\nwhen fetching for the missing objects, the promisor remote \"prom2\" will be\nqueried first before \"prom1\".\n\n2. Server Side Advertisement:\n-----------------------------\nAfter the `remote..priority` config option has been implemented and the\nfetch order can be changed, I will then allow the server to advertise its\nrecommended fetch order in the promisor-remote capability.\n\nAs the server knows about the promisor remotes which hold the\nmissing objects, it could recommend the order in which these remotes\ncould be queried by the client using a \"priority=\" field of the\npromisor-remote capability in the Git v2 protocol, where could\nbe an integer between 1 and 65535, and the smallest integer indicates\nhighest priority.\n\nThis will be an optional feature which will be enabled by the server\nif it wants to recommend ordered fetching to the client via\nthe \"promisor.sendFields=priority\" config option.\n\nHence if the server advertises promisor remotes prom1 and prom2,\nit could be of the form\n\n \"promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20\",\n\nif the server is configured as:\n\n[remote \"prom1\"]\n url = https://prom1.com\n priority = 10\n[remote \"prom2\"]\n url = https://prom2.com\n priority = 20\n\nIf the \"promisor.sendFields\" values does not include the \"priority\"\nfield in its comma or space separated options, the field will not be\nadvertised in the promisor-remote capability.\n\n3. Client Side Parsing:\n-----------------------\nAfter the \"priority\" field has been advertised in the promisor-remote\ncapability, the client can choose to use this server recommended fetch\norder or ignore it completely.\nIf the client wants to use the server recommended fetch order later when\nfetching the missing objects from the accepted promisor remotes, the \"priority\"\nfield will be added to the \"promisor.storeFields\" config\noptions so that the passed value can be saved to the client config.\nIf the client does not enable this option in the config, the \"priority\"\nfield will not be saved in the local config and the fetching order will\nbe client specified order if set or the default local config order if not set.\n\nThe three different fetch order are;\n1. the order advertised by the server, where the \"priority\" field\n will be added to \"promisor.storeFields\" and the value will be saved to the\n local config file for the selected promisor remotes. When fetching the missing\n objects, this order will be used.\n2. the local \"priority\" config where the client can set the \"priority\"\n field using, priority=, of some or all \"remote.\" to indicate its preferred\n fetch order when fetching the missing objects.\n This order will be used if the \"promisor.storeFields\" does not include the\n \"priority\" field.\n3. the default order, where the field will not be added to the config and hence\n the current default order will be used.\n\nProposed Project Execution Timeline:\n====================================\n\n1. Study code base to understand promisor-remote and fetch mechanism (May 1 - 14, 2026):\n -------------------------------------------------------------------------------------\n- Study the code base to understand how the client and server\n communicate using the protocol when client contacts the server.\n- Study how Git currently handles fetching from multiple remotes.\n- Set up blog for posting once in two weeks\n\n2. Community Bonding (May 1 - 14, 2026):\n----------------------------------------\n- Discuss design details with community and mentors\n- Understand safety, security constraints and design considerations\n when implementing fetch ordering.\n- Read indepth the Documentations for promisor-remote, gitprotocol-v2,\n and other necessary documentations.\n- Post updates on my blog\n\n3. Review Existing Patches and related code (May 15 - May 25, 2026):\n-------------------------------\n- Study code base to understand how a new config option is added.\n- study code that handles the fetching of missing objects after a partial\n clone/fetch.\n- Study Christian's patches in-depth to understand how a new field is\n added to the promisor remote of server, what conditions\n are used to ensure the data is of the right format, correctly passed from\n server to client, and correctly parsed and stored by client.\n- Study how a client can store the new field it accepts to use from the\n advertised fields.\n- Understand the tests to see how these new features are tested\n- Post updates on my blog\n\n4. Introduce the `remote..priority` config option: (May 25 - June 13, 2026):\n-------------------------------------------------------\n- Discuss with mentors on the suggested approach\n- Allow the addition of the config option `remote..priority`\n- Implement fetching based on this option when set by the client\n and if not set, default to the current order.\n- Write tests to ensure proper implementation of the new config and\n fetch order\n- Submit patches to mailing list and engage in reviews with Community members\n- Post update on my blog\n\n5. Allow a server to add the \"priority\" field to the promisor-remote capability (June 14 - June 21, 2026)\n-------------------------------------------------------------------------------\n- Discuss with mentors on the suggested approach\n- Allow the server to add the field \"priority\" to the promisor-remote\n capability when it is enabled in \"promisor.sendFields\".\n- Write tests to ensure proper implementation\n- Update documentation in Documenantation/config/promisor.adoc\n- Submit patch to mailing list for discussions and address reviews\n- Post updates on my blog\n\n6. Allow Client to decide to use the field (June 21 - 14, 2026):\n-----------------------------------------------------------------\n- Discuss strategy with mentors\n- Allow the client to store the \"priority\" in its .git/config if it\n accepts the promisor remotes and it is included in \"promisor.storeFields\"\n- Write unit tests to ensure proper implementations\n- Update documentation in Documentation/config/promisor.adoc\n- Submit patches to mailing list for reviews and address feedbacks\n- Post updates on my blog\n\n7. Implement fetching order based on setting: (July 15 - August 14, 2026):\n------------------------------------------------------------------------\n- Discuss with mentors on the approach and considerations for fetch order\n- Implement fetching based on the client's accepted fetching order\n- Write unittests to test implementation\n- Update documentation in Documenantation/config/promisor.adoc\n- Submit patches for review and address reviews\n- Post updates on my blog\n\n9. Final Report on Project (August 15 - 24, 2026):\n--------------------------------------------------\n- Document any final report in my blog with details of my experience\n- Finalize any pending tasks\n\nAvailability:\n=============\nI will be able to give 30 hours a week to make the project a success\n\nPost GSoC\n=========\n\nThough this is not my first contribution to Git, as I have contributed\nvery lightly to the codebase before, I am committed to\ncontinuously contributing to Git and become a part of the next set\nof contributors to champion the continuous development of Git.\n\nAppreciation\n============\nTo Junio C Hamano, Phillip Wood, and everyone who helped with my patches.\nI really appreciate your guidance, patience and direction while\nreviewing and my patches.\n\nThanks\n\nReferences\n===========\n1. https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/\n2. https://lore.kernel.org/git/20250908053056.956907-1-christian.couder@gmail.com/\n3. https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/\n"},{"id":"538459","messageId":"CADYq+fbDVWNfomJ-UEU0QsEAmHoS9pa03aW5wOjBTyQfD2ojHQ@mail.gmail.com","threadId":"65103","inReplyTo":"CAP8UFD1kzuP8sYKzTJkvf08OazrMzESQ+qZNW8=Qss3DDw=OeA@mail.gmail.com","subject":"Re: [GSoC] [Proposal]: Implement promisor remote fetch ordering","fromName":"Samuel Abraham","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-10T15:11:15Z","receivedAt":"2026-03-10T15:11:16Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"On Tue, Mar 3, 2026 at 10:27 AM Christian Couder\n wrote:\n>\n> Hi,\n>\n> On Sun, Mar 1, 2026 at 12:27 AM Abraham Samuel Adekunle\n> wrote:\n> >\n> > Hello,\n> > This is my proposal for the project\n> > \"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n>\n> Thanks for being interested in Git and this project in particular.\n>\n\nHello Christian.\nThank you for taking out time to review my proposal.\nI have made your recommended changes and sent a v2.\n\nThanks\nAbraham\n"},{"id":"539201","messageId":"CADYq+fb+MdpUTgLbcfoh380jiXi8HCZZbKaxgZDtb-rxrxC9zg@mail.gmail.com","threadId":"65103","inReplyTo":"aafga8AjpxagiEJt@Adekunles-MacBook-Air.local","subject":"Re: [GSoC] [Proposal v2]: Implement promisor remote fetch ordering","fromName":"Samuel Abraham","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-17T07:53:47Z","receivedAt":"2026-03-17T07:53:49Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"On Wed, Mar 4, 2026 at 8:35 AM Abraham Samuel Adekunle\n wrote:\n>\n> Hello,\n> This is the second iteration of my proposal for the project\n> \"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n>\n> Personal Bio:\n> =============\n> Full Name: Abraham Samuel Adekunle\n> Email: abrahamadekunle50@gmail.com\n> GitHub: https://github.com/devdekunle\n> Pronouns: he/him\n>\n\nHello, Just bumping this up to get reviews for my GSoC proposal v2.\n\nThanks\nAbraham\n"},{"id":"539831","messageId":"CAP8UFD16pvfP4UYJHCCenK3c1-VNTJPpMBJL_LnHZZZXUC5ULA@mail.gmail.com","threadId":"65103","inReplyTo":"aafga8AjpxagiEJt@Adekunles-MacBook-Air.local","subject":"Re: [GSoC] [Proposal v2]: Implement promisor remote fetch ordering","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-24T12:29:04Z","receivedAt":"2026-03-24T12:29:17Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Mar 4, 2026 at 8:35 AM Abraham Samuel Adekunle\n wrote:\n\n> When a Git repository is configured with multiple promisor remotes,\n> there is currently no other mechanism to specify or optimize the order in\n> which these remotes should be queried when fetching missing objects.\n> Different remotes may have different performance characteristics\n> such as characteristics, cost, or reliability which makes the\n\nThere is a repetition of \"characteristics\" above.\n\n> fetching order an important consideration.\n> Currently, the promisor remotes are queried in the order in which they\n> appear in the local .git/config.\n\nThere is the exception of the `extensions.partialClone` config variable.\n\nAlso I recently sent a patch series that might change things (see the\nfirst patch in the series introduced by\nhttps://lore.kernel.org/git/20260323080520.887550-1-christian.couder@gmail.com/),\nbut it's not merged, so don't rewrite your proposal to take it into\naccount.\n\n> The project aims to implement a fetch ordering mechanism for multiple\n> promisor remotes that allows a client to be able to specify a fetching order,\n> a server to advertise an order to the client to ensure performance\n> and cost management, and the client to decide to use the server advertised\n> order or not, and default to the current order if no order is specified.\n>\n> Review of Previous Work:\n> ========================\n> The project is part of the Large Object Promisor \"LOP\" effort\n> documented in Documentation/technical/large-object-promisors.adoc.\n>\n> In a bid to better handle large objects, the promisor-remote\n> capability was added to the Git protocol v2, as documented in\n> the promisor-remote section of Documentation/gitprotocol-v2.adoc,\n> which enables a protocol negotiation so that the server can advertise\n> one or more promisor remotes and so that the client and server can\n> discuss if the client could directly use a promisor remote the server\n> is advertising and if an agreement is reached, the client would be\n> able to get the missing objects directly from the promisor remote without\n> the server acting as a relay between the client and the promisor remote when\n> fetching missing objects.\n\nYou might want to split this very long sentence into a few smaller ones.\n\n> The ground work for adding this capability to the v2 protocol was\n> started by Christian Couder in [1], where if the \"promisor.advertise\"\n> config is set to true, the server can then propagate its promisor remote\n> configurations to the client over the v2 protocol during the negotiation\n> in the form\n>\n> \"promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2\"\n>\n> The client can then choose to accept some promisor remotes the server\n> is advertising using the \"All\", \"None\", \"KnownName\" or \"KnownUrl\"\n> configurations as values for the \"promisor.acceptfromServer\" config option.\n>\n> In [2], Christian added the option for a server to advertise more\n> fields after the \"name\" and \"url\", such as \"token\" and\n> \"partialCloneFilter\" for the client to use this additional information\n> in deciding the remotes to use as its promisor remotes by comparing it\n> with its local config information.\n>\n> This was implemented by adding the \"promisor.sendFields\" and\n> \"promisor.checkFields\" config values to the server and client respectively.\n> For example, if \"promisor.sendFields\" is set to \"partialCloneFilter\", and the\n> server has the remote configured like so:\n> [remote \"foo\"]\n> url = https://pr.test\n> partialCloneFilter = blob:none\n> token = \"fake\"\n> then\n>\n> \"name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake\"\n> will be advertised by the server to the client who can then decide,\n> using the \"promisor.checkFields\" setting, to check if the passed field\n> matches certain conditions before deciding to use it.\n\nThe \"promisor.checkFields\" config variable is not quite to decide if\nfields can be used, but more to decide if they should be checked\nbefore the remote is accepted.\n\nUsing the \"promisor.storeFields\" config option is better if fields\nshould be used.\n\n> This work by Christian is very crucial to this project as I will take\n> advantage of this and enable the advertisement of a \"priority\" field\n> that the server can use to communicate with the client in deciding to\n> use the server recommended fetch order or not.\n>\n> in [3] Christian also implemented the option \"promisor.storeFields\" which\n> allowed the value of the configuration to be saved in the client's\n> configuration file for use at a later time.\n> As above, this option will also prove important when the server advertises\n> the \"priority\" field as it will allow the client decided to store it in its\n\nMaybe: s/decided //\n\n> config settings for that promisor remote, for later use when fetching\n> the remaining blobs from the promisor remotes.\n\nYes.\n\n[...]\n\n> High Level Approach to Project Execution:\n> =========================================\n>\n> 1. Introduce the `remote..priority` config option:\n> ======================================================\n> As said above, when fetching missing objects, the order in which the remotes\n> are queried depends on the order in which they appear in the config file.\n\nNot sure this is worth repeating three times.\n\n> To make this flexible, I will introduce the `remote..priority` config option,\n> which will allow the client to set its preferred fetch order to each promisor remote\n> configuration, and then make it fetch based on this \"priority\" order.\n> The value of this option could be an integer between 1 and 65535, where the smallest\n\nWhy 65535?\n\n> integer indicates highest priority.\n>\n> This will allow a promisor remote be configured as follows\n>\n> [remote \"prom1\"]\n> url = https://prom1.com\n> priority = 10\n>\n> Therefore when the client is configured with more than one promisor remote\n> and the prority is set for each promisor remote as follows,\n\ns/prority/priority/\n\n> [remote \"prom1\"]\n> url = https://prom1.com\n> priority = 20\n> [remote \"prom2\"]\n> url = https://prom2.com\n> priority = 10,\n\n[...]\n\n> 2. Community Bonding (May 1 - 14, 2026):\n> ----------------------------------------\n> - Discuss design details with community and mentors\n> - Understand safety, security constraints and design considerations\n> when implementing fetch ordering.\n> - Read indepth the Documentations for promisor-remote, gitprotocol-v2,\n\ns/indepth/in depth/\n\n> and other necessary documentations.\n\nThanks.\n"},{"id":"539853","messageId":"CADYq+fZfaFyOd++wT3gTbMNxT7ArGEzmYc09ydOHuSAnu5QcFw@mail.gmail.com","threadId":"65103","inReplyTo":"CAP8UFD16pvfP4UYJHCCenK3c1-VNTJPpMBJL_LnHZZZXUC5ULA@mail.gmail.com","subject":"Re: [GSoC] [Proposal v2]: Implement promisor remote fetch ordering","fromName":"Samuel Abraham","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-24T15:58:00Z","receivedAt":"2026-03-24T15:58:02Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"On Tue, Mar 24, 2026 at 1:29 PM Christian Couder\n wrote:\n>\n> Hi,\n>\n> On Wed, Mar 4, 2026 at 8:35 AM Abraham Samuel Adekunle\n> wrote:\n>\n> > When a Git repository is configured with multiple promisor remotes,\n> > there is currently no other mechanism to specify or optimize the order in\n> > which these remotes should be queried when fetching missing objects.\n> > Different remotes may have different performance characteristics\n> > such as characteristics, cost, or reliability which makes the\n>\n> There is a repetition of \"characteristics\" above.\n\nOh thanks\n\n>\n> > fetching order an important consideration.\n> > Currently, the promisor remotes are queried in the order in which they\n> > appear in the local .git/config.\n>\n> There is the exception of the `extensions.partialClone` config variable.\n\nYes, I stated it below. I will probably bring the statement here.\n\n>\n> Also I recently sent a patch series that might change things (see the\n> first patch in the series introduced by\n> https://lore.kernel.org/git/20260323080520.887550-1-christian.couder@gmail.com/),\n> but it's not merged, so don't rewrite your proposal to take it into\n> account.\n\nYes, I took a brief look when you submitted it to the mailing list yesterday.\nThanks and well done Christian, I will keep up with the series.\n\n>\n> > The project aims to implement a fetch ordering mechanism for multiple\n> > promisor remotes that allows a client to be able to specify a fetching order,\n> > a server to advertise an order to the client to ensure performance\n> > and cost management, and the client to decide to use the server advertised\n> > order or not, and default to the current order if no order is specified.\n> >\n> > Review of Previous Work:\n> > ========================\n> > The project is part of the Large Object Promisor \"LOP\" effort\n> > documented in Documentation/technical/large-object-promisors.adoc.\n> >\n> > In a bid to better handle large objects, the promisor-remote\n> > capability was added to the Git protocol v2, as documented in\n> > the promisor-remote section of Documentation/gitprotocol-v2.adoc,\n> > which enables a protocol negotiation so that the server can advertise\n> > one or more promisor remotes and so that the client and server can\n> > discuss if the client could directly use a promisor remote the server\n> > is advertising and if an agreement is reached, the client would be\n> > able to get the missing objects directly from the promisor remote without\n> > the server acting as a relay between the client and the promisor remote when\n> > fetching missing objects.\n>\n> You might want to split this very long sentence into a few smaller ones.\n\nOkay I will.\n\n>\n> > The ground work for adding this capability to the v2 protocol was\n> > started by Christian Couder in [1], where if the \"promisor.advertise\"\n> > config is set to true, the server can then propagate its promisor remote\n> > configurations to the client over the v2 protocol during the negotiation\n> > in the form\n> >\n> > \"promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2\"\n> >\n> > The client can then choose to accept some promisor remotes the server\n> > is advertising using the \"All\", \"None\", \"KnownName\" or \"KnownUrl\"\n> > configurations as values for the \"promisor.acceptfromServer\" config option.\n> >\n> > In [2], Christian added the option for a server to advertise more\n> > fields after the \"name\" and \"url\", such as \"token\" and\n> > \"partialCloneFilter\" for the client to use this additional information\n> > in deciding the remotes to use as its promisor remotes by comparing it\n> > with its local config information.\n> >\n> > This was implemented by adding the \"promisor.sendFields\" and\n> > \"promisor.checkFields\" config values to the server and client respectively.\n> > For example, if \"promisor.sendFields\" is set to \"partialCloneFilter\", and the\n> > server has the remote configured like so:\n> > [remote \"foo\"]\n> > url = https://pr.test\n> > partialCloneFilter = blob:none\n> > token = \"fake\"\n> > then\n> >\n> > \"name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake\"\n> > will be advertised by the server to the client who can then decide,\n> > using the \"promisor.checkFields\" setting, to check if the passed field\n> > matches certain conditions before deciding to use it.\n>\n> The \"promisor.checkFields\" config variable is not quite to decide if\n> fields can be used, but more to decide if they should be checked\n> before the remote is accepted.\n\nOkay thanks.\n\n>\n> Using the \"promisor.storeFields\" config option is better if fields\n> should be used.\n\nYes thanks\n\n>\n> > This work by Christian is very crucial to this project as I will take\n> > advantage of this and enable the advertisement of a \"priority\" field\n> > that the server can use to communicate with the client in deciding to\n> > use the server recommended fetch order or not.\n> >\n> > in [3] Christian also implemented the option \"promisor.storeFields\" which\n> > allowed the value of the configuration to be saved in the client's\n> > configuration file for use at a later time.\n> > As above, this option will also prove important when the server advertises\n> > the \"priority\" field as it will allow the client decided to store it in its\n>\n> Maybe: s/decided //\n\nThanks\n\n>\n> > config settings for that promisor remote, for later use when fetching\n> > the remaining blobs from the promisor remotes.\n>\n> Yes.\n>\n> [...]\n>\n> > High Level Approach to Project Execution:\n> > =========================================\n> >\n> > 1. Introduce the `remote..priority` config option:\n> > ======================================================\n> > As said above, when fetching missing objects, the order in which the remotes\n> > are queried depends on the order in which they appear in the config file.\n>\n> Not sure this is worth repeating three times.\n\nOkay\n\n>\n> > To make this flexible, I will introduce the `remote..priority` config option,\n> > which will allow the client to set its preferred fetch order to each promisor remote\n> > configuration, and then make it fetch based on this \"priority\" order.\n> > The value of this option could be an integer between 1 and 65535, where the smallest\n>\n> Why 65535?\n\nI considered if the value might be stored in a small unsigned 16 bit\ninteger type\nand also it will have enough room for many priority levels.\nBut we must not use the exact range (0 - 65535).\n\n>\n> > integer indicates highest priority.\n> >\n> > This will allow a promisor remote be configured as follows\n> >\n> > [remote \"prom1\"]\n> > url = https://prom1.com\n> > priority = 10\n> >\n> > Therefore when the client is configured with more than one promisor remote\n> > and the prority is set for each promisor remote as follows,\n>\n> s/prority/priority/\n\nThanks\n\n>\n> > [remote \"prom1\"]\n> > url = https://prom1.com\n> > priority = 20\n> > [remote \"prom2\"]\n> > url = https://prom2.com\n> > priority = 10,\n>\n> [...]\n>\n> > 2. Community Bonding (May 1 - 14, 2026):\n> > ----------------------------------------\n> > - Discuss design details with community and mentors\n> > - Understand safety, security constraints and design considerations\n> > when implementing fetch ordering.\n> > - Read indepth the Documentations for promisor-remote, gitprotocol-v2,\n>\n> s/indepth/in depth/\n\nThank you. I will make the changes and send a v3.\n\nThanks\n\nAbraham.\n"},{"id":"539890","messageId":"acMT0zqd6SiEz5h9@Adekunles-MacBook-Air.local","threadId":"65103","inReplyTo":"aafga8AjpxagiEJt@Adekunles-MacBook-Air.local","subject":"[GSoC] [Proposal v3]: Implement promisor remote fetch ordering","fromName":"Abraham Samuel Adekunle","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-24T22:47:54Z","receivedAt":"2026-03-24T22:47:48Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"Hello,\nThis is the third iteration of my proposal for the project\n\"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n\nPersonal Bio:\n=============\nFull Name: Abraham Samuel Adekunle\nEmail: abrahamadekunle50@gmail.com\nGitHub: https://github.com/devdekunle\nPronouns: he/him\n\nAbout Me:\n=========\nMy name is Abraham Samuel Adekunle. I love to code, read and I am a\nhard worker. In my free time I love to play games and listen to soothing\nmusic and well, also shift into diffuse thinking to gain a new\nperspective of whatever challenge I am trying to solve.\n\nI am very curious so I really love to learn as it's a never ending\njourney, and I believe in the power of \"yet\".\nI can understand anything, it is only a matter of time and effort.\nI love to figure out things and be part of a community\nwhere we can share experiences and support each other in growth.\n\nPast Experience with Git:\n=========================\nI first learnt about Git during my ALX Software Engineering days in\n2022, it proved challenging at first understanding what was going on\nand a git merge conflict was always a scary experience.\nNow I feel elated actually contributing to this renowned project.\n\nContributions to the Git Community:\n====================================\nMy first contribution to the Git community was during the contribution\nphase of the December 2024 Outreachy contribution phase where I first\nlearned to send patches and had my first interactions with the Git code\nbase. I did not make it through then but it was an opportunity to try\nagain.\n\nContributions to other Communities:\n===================================\nI have contributed very sparingly to the Systemd project and also\nthe Linux Kernel.\n\nMicroproject:\n=============\nLink: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/\nBranch: aa/add-p-previous-decisions\nStatus: Merged to master\nCommit ID: 8cafc305e22a59efb92472d4132616e24d3184c6\nDescription: \"git add -p\" and friends notes what the current status\n of the hunk being shown is\n\nOther Contributions:\n====================\n1.\nLink: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/\nBranch: aa/add-p-no-auto-advance\nStatus: Will merge to master\nDescription: \"git add -p\" learned a new mode that allows the user to\n revisit a file that was already dealt with\n\n2.\nLink: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/\nStatus: Stalled\nDescription: the patch attempts to remove the use of the_repository\n global variable in some builtins\n\n3.\nLink: https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@gmail.com/\nBranch: sa/notes-edit\nStatus: Merged to master\nDescription: Teach 'git notes add' and 'git notes append' a new '-e' flag,\n instructing them to open the note in $GIT_EDITOR before saving.\n\n4.\nLink: https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@gmail.com/\nBranch: aa/t7300-modernize\nStatus: Merged to master\nDescription: use test_path_* helper functions for error logging\n\nProject Overview and Objective:\n===============================\nI have always wondered what happens in the background when I see these\ndetails on my screen in a \"git fetch\" process.\n\n remote: Enumerating objects: 57, done.\n remote: Counting objects: 100% (57/57), done.\n remote: Compressing objects: 100% (12/12), done.\n Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done.\n Resolving deltas: 100% (21/21), done.\n remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30\n From https://example.com/me/repo\n 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz\n\nAnd when I saw this project from the list of projects listed,\nI was endeared to it as it is an opportunity to work in an area of the\nthat Git code base that will satisfy my curiosity while also being\nmentored by very best and most experienced Engineers there is.\n\nWhen a Git repository is configured with multiple promisor remotes,\nthere is currently no other mechanism to specify or optimize the order in\nwhich these remotes should be queried when fetching missing objects.\nDifferent remotes may have different performance characteristics, cost, or\nreliability which makes the fetching order an important consideration.\n\nCurrently, the promisor remotes are queried in the order in which they\nappear in the local .git/config, one after the other, until all the objects have\nbeen fetched, with the promisor remote configured with the `extension.partialClone`\nconfig variable being the last one tried.\n\nThe project aims to implement a fetch ordering mechanism for multiple\npromisor remotes that allows a client to be able to specify a fetching order,\na server to advertise an order to the client to ensure performance\nand cost management, the client to decide to use the server advertised\norder or not, and default to the current order if no order is specified.\n\n\nReview of Previous Work:\n========================\nThe project is part of the Large Object Promisor \"LOP\" effort\ndocumented in Documentation/technical/large-object-promisors.adoc.\n\nIn a bid to better handle large objects, the promisor-remote\ncapability was added to the Git protocol v2, as documented in\nthe promisor-remote section of Documentation/gitprotocol-v2.adoc.\n\nThis enables a protocol negotiation so that the server can advertise\none or more promisor remotes and the client and server can\ndiscuss if the client could directly fetch missing objects from the promisor\nremote(s) the server is advertising.\nIf an agreement is reached, the client would be able to fetch the missing\nobjects directly from the promisor remote without the server acting as\na relay between the client and the promisor remote.\n\nThe ground work for adding this capability to the v2 protocol was\nstarted by Christian Couder in [1], where if the \"promisor.advertise\"\nconfig is set to true, the server can then propagate its promisor remote\nconfigurations to the client over the v2 protocol during the negotiation\nin the form\n\n \"promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2\"\n\nThe client can then choose to accept some promisor remotes the server\nis advertising using the \"All\", \"None\", \"KnownName\" or \"KnownUrl\"\nconfigurations as values for the \"promisor.acceptfromServer\" config option.\n\nIn [2], Christian added the option for a server to advertise more\nfields after the \"name\" and \"url\", such as \"token\" and\n\"partialCloneFilter\" for the client to use this additional information\nin deciding the remotes to use as its promisor remotes by comparing it\nwith its local config information.\n\nThis was implemented by adding the \"promisor.sendFields\" and\n\"promisor.checkFields\" config values to the server and client respectively.\nFor example, if \"promisor.sendFields\" is set to \"partialCloneFilter\", and the\nserver has the remote configured like so:\n[remote \"foo\"]\n url = https://pr.test\n partialCloneFilter = blob:none\n token = \"fake\"\nthen\n\n \"name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake\"\nwill be advertised by the server to the client which can then decide,\nusing the \"promisor.checkFields\" config option, to check if the passed field\nmatches certain conditions before the remote is accepted.\n\nin [3] Christian also implemented the option \"promisor.storeFields\" which\nallowed the value of the configuration to be saved in the client's\nconfiguration file for use at a later time.\n\nOne fetch order that I will implement is the server recommended fetch order,\nwhich the server suggests to the client.\nTo achieve this, I would take advantage of the ground work done by Christian\nby adding a \"priority\" field to the promisor-remote capability when the \"priority\"\nis added to the \"promisor.sendFields\" server config option. This indicates that the\nserver is recommending to the client to use its recommended fetch order.\n\nIf the client chooses to use the server recommended fetch order, it can\nadd \"priority\" to the \"promisor.storeFields\" config option which will store\nthis value and query the promisor remotes in the recommended order when fetching\nthe missing objects at a later time.\n\nIf the client chooses to ignore this recommendation, it can simply choose not to\nstore it and instead use its own preferred order by setting the priority for\nsome or all the remotes to its preferred value and then query the objects in that order.\nNot using either of these orders will query the promisor remotes in the current\ndefault order.\n\nHigh Level Approach to Project Execution:\n=========================================\n\n1. Introduce the `remote..priority` config option:\n======================================================\nTo make the fetch order flexible, the first step will be to introduce the\n`remote..priority` config option, which will allow the client to set its\npreferred fetch order to each promisor remote configuration, and then make it\nfetch based on this \"priority\" order.\n\nThe value of this option could be a fixed range between 1 - 100 where the smallest\ninteger indicates highest priority.\n\nThis will allow a promisor remote be configured as follows\n\n [remote \"prom1\"]\n url = https://prom1.com\n priority = 10\n\nTherefore when the client is configured with more than one promisor remote\nand the prority is set for each promisor remote as follows,\n\n [remote \"prom1\"]\n url = https://prom1.com\n priority = 20\n [remote \"prom2\"]\n url = https://prom2.com\n priority = 10,\n\nwhen fetching for the missing objects, the promisor remote \"prom2\" will be\nqueried first before \"prom1\".\n\n2. Server Side Advertisement:\n-----------------------------\nAfter the `remote..priority` config option has been implemented and the\nfetch order can be changed, I will then allow the server to advertise its\nrecommended fetch order in the promisor-remote capability.\n\nAs the server knows about the promisor remotes which hold the\nmissing objects, it could recommend the order in which these remotes\ncould be queried by the client using a \"priority=\" field of the\npromisor-remote capability in the Git v2 protocol, where could\nbe a fixed range integer between 1 and 100, and the smallest integer indicates\nhighest priority.\n\nThis will be an optional feature which will be enabled by the server\nif it wants to recommend ordered fetching to the client via\nthe \"promisor.sendFields=priority\" config option.\n\nHence if the server advertises promisor remotes prom1 and prom2,\nit could be of the form\n\n \"promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20\",\n\nif the server is configured as:\n\n[remote \"prom1\"]\n url = https://prom1.com\n priority = 10\n[remote \"prom2\"]\n url = https://prom2.com\n priority = 20\n\nIf the \"promisor.sendFields\" values does not include the \"priority\"\nfield in its comma or space separated options, the field will not be\nadvertised in the promisor-remote capability.\n\n3. Client Side Parsing:\n-----------------------\nAfter the \"priority\" field has been advertised in the promisor-remote\ncapability, the client can choose to use this server recommended fetch\norder or ignore it completely.\nIf the client wants to use the server recommended fetch order later when\nfetching the missing objects from the accepted promisor remotes, the \"priority\"\nfield will be added to the \"promisor.storeFields\" config\noptions so that the passed value can be saved to the client config.\nIf the client does not enable this option in the config, the \"priority\"\nfield will not be saved in the local config and the fetching order will\nbe client specified order if set or the default local config order if not set.\n\nThe three different fetch order are;\n1. the order advertised by the server, where the \"priority\" field\n will be added to \"promisor.storeFields\" and the value will be saved to the\n local config file for the selected promisor remotes. When fetching the missing\n objects, this order will be used.\n2. the local \"priority\" config where the client can set the \"priority\"\n field using, priority=, of some or all \"remote.\" to indicate its preferred\n fetch order when fetching the missing objects.\n This order will be used if the \"promisor.storeFields\" does not include the\n \"priority\" field.\n3. the default order, where the field will not be added to the config and hence\n the current default order will be used.\n\nProposed Project Execution Timeline:\n====================================\nEstimated Project Size: 350 hours\n\n1. Study code base to understand promisor-remote and fetch mechanism (May 1 - 14, 2026):\n -------------------------------------------------------------------------------------\n- Study the code base to understand how the client and server\n communicate using the protocol when client contacts the server.\n- Study how Git currently handles fetching from multiple remotes.\n- Set up blog for posting once in two weeks\n\n2. Community Bonding (May 1 - 14, 2026):\n----------------------------------------\n- Discuss design details with community and mentors\n- Understand safety, security constraints and design considerations\n when implementing fetch ordering.\n- Read in depth the Documentations for promisor-remote, gitprotocol-v2,\n and other necessary documentations.\n- Post updates on my blog\n\n3. Review Existing Patches and related code (May 15 - May 25, 2026):\n-------------------------------\n- Study code base to understand how a new config option is added.\n- study code that handles the fetching of missing objects after a partial\n clone/fetch.\n- Study Christian's patches in-depth to understand how a new field is\n added to the promisor remote of server, what conditions\n are used to ensure the data is of the right format, correctly passed from\n server to client, and correctly parsed and stored by client.\n- Study how a client can store the new field it accepts to use from the\n advertised fields.\n- Understand the tests to see how these new features are tested\n- Post updates on my blog\n\n4. Introduce the `remote..priority` config option: (May 25 - June 13, 2026):\n-------------------------------------------------------\n- Discuss with mentors on the suggested approach\n- Allow the addition of the config option `remote..priority`\n- Implement fetching based on this option when set by the client\n and if not set, default to the current order.\n- Write tests to ensure proper implementation of the new config and\n fetch order\n- Submit patches to mailing list and engage in reviews with Community members\n- Post update on my blog\n\n5. Allow a server to add the \"priority\" field to the promisor-remote capability (June 14 - June 21, 2026)\n-------------------------------------------------------------------------------\n- Discuss with mentors on the suggested approach\n- Allow the server to add the field \"priority\" to the promisor-remote\n capability when it is enabled in \"promisor.sendFields\".\n- Write tests to ensure proper implementation\n- Update documentation in Documenantation/config/promisor.adoc\n- Submit patch to mailing list for discussions and address reviews\n- Post updates on my blog\n\n6. Allow Client to decide to use the field (June 21 - 14, 2026):\n-----------------------------------------------------------------\n- Discuss strategy with mentors\n- Allow the client to store the \"priority\" in its .git/config if it\n accepts the promisor remotes and it is included in \"promisor.storeFields\"\n- Write unit tests to ensure proper implementations\n- Update documentation in Documentation/config/promisor.adoc\n- Submit patches to mailing list for reviews and address feedbacks\n- Post updates on my blog\n\n7. Implement fetching order based on setting: (July 15 - August 14, 2026):\n------------------------------------------------------------------------\n- Discuss with mentors on the approach and considerations for fetch order\n- Implement fetching based on the client's accepted fetching order\n- Write unittests to test implementation\n- Update documentation in Documenantation/config/promisor.adoc\n- Submit patches for review and address reviews\n- Post updates on my blog\n\n9. Final Report on Project (August 15 - 24, 2026):\n\n--------------------------------------------------\n- Document any final report in my blog with details of my experience\n- Finalize any pending tasks\n\nAvailability:\n=============\nI will be able to give 30 hours a week to make the project a success\n\nPost GSoC\n=========\n\nThough this is not my first contribution to Git, as I have contributed\nvery lightly to the codebase before, I am committed to\ncontinuously contributing to Git and become a part of the next set\nof contributors to champion the continuous development of Git.\n\nAppreciation\n============\nTo Junio C Hamano, Phillip Wood, and everyone who helped with my patches.\nI really appreciate your guidance, patience and direction while\nreviewing and my patches.\n\nThanks\n\nReferences\n===========\n1. https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/\n2. https://lore.kernel.org/git/20250908053056.956907-1-christian.couder@gmail.com/\n3. https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/\n"},{"id":"540431","messageId":"CADYq+fbsXVtYZcq2wB2FoyUzDdzZKJYEN2EZk1uOvdihMyJzVA@mail.gmail.com","threadId":"65103","inReplyTo":"acMT0zqd6SiEz5h9@Adekunles-MacBook-Air.local","subject":"Re: [GSoC] [Proposal v3]: Implement promisor remote fetch ordering","fromName":"Samuel Abraham","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-30T21:50:10Z","receivedAt":"2026-03-30T21:50:11Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"On Tue, Mar 24, 2026 at 11:47 PM Abraham Samuel Adekunle\n wrote:\n>\n> Hello,\n> This is the third iteration of my proposal for the project\n> \"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n>\nHello.\n\nJust bumping this up to know if this version is okay for submission to\nthe GSoC site.\nThanks\n\nAbraham.\n"},{"id":"540483","messageId":"CAP8UFD3xsMc+irB0Aiit3rMqHeSqodeKpSRRvjOKFGF-vvmx-Q@mail.gmail.com","threadId":"65103","inReplyTo":"CADYq+fbsXVtYZcq2wB2FoyUzDdzZKJYEN2EZk1uOvdihMyJzVA@mail.gmail.com","subject":"Re: [GSoC] [Proposal v3]: Implement promisor remote fetch ordering","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-31T07:25:52Z","receivedAt":"2026-03-31T07:26:06Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Mon, Mar 30, 2026 at 11:50 PM Samuel Abraham\n wrote:\n>\n> On Tue, Mar 24, 2026 at 11:47 PM Abraham Samuel Adekunle\n> wrote:\n> >\n> > Hello,\n> > This is the third iteration of my proposal for the project\n> > \"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n> >\n> Hello.\n>\n> Just bumping this up to know if this version is okay for submission to\n> the GSoC site.\n> Thanks\n\nSorry but we won't likely have time to review your proposal and other\nproposals before the end of the application period today at 18:00 UTC.\n\nSo everyone should submit their proposal on the GSoC site as-is now if\nthey haven't already done so.\n\nBest,\nChristian.\n"},{"id":"540500","messageId":"CADYq+fZGtWz62U-ur50_Ee+KvA0BPvXPPQ1dNwsx0+qxPdydHA@mail.gmail.com","threadId":"65103","inReplyTo":"CAP8UFD3xsMc+irB0Aiit3rMqHeSqodeKpSRRvjOKFGF-vvmx-Q@mail.gmail.com","subject":"Re: [GSoC] [Proposal v3]: Implement promisor remote fetch ordering","fromName":"Samuel Abraham","fromEmail":"abrahamadekunle50@gmail.com","sentAt":"2026-03-31T10:10:51Z","receivedAt":"2026-03-31T10:10:52Z","isPatch":false,"sender":{"key":"abrahamadekunle50@gmail.com","avatar":"https://avatars.githubusercontent.com/u/110066922?v=4"},"body":"On Tue, Mar 31, 2026 at 8:26 AM Christian Couder\n wrote:\n>\n> Hi,\n>\n> On Mon, Mar 30, 2026 at 11:50 PM Samuel Abraham\n> wrote:\n> >\n> > On Tue, Mar 24, 2026 at 11:47 PM Abraham Samuel Adekunle\n> > wrote:\n> > >\n> > > Hello,\n> > > This is the third iteration of my proposal for the project\n> > > \"Implement promisor remote fetch ordering\" for the 2026 GSoC programme.\n> > >\n> > Hello.\n> >\n> > Just bumping this up to know if this version is okay for submission to\n> > the GSoC site.\n> > Thanks\n>\n> Sorry but we won't likely have time to review your proposal and other\n> proposals before the end of the application period today at 18:00 UTC.\n>\n> So everyone should submit their proposal on the GSoC site as-is now if\n> they haven't already done so.\n>\nThank you Christian\nI will do that\n\nAbraham\n"}]}