# [GSoC] [Proposal]: Implement promisor remote fetch ordering 12 messages from 2026-02-28 to 2026-03-31. Participants: Abraham Samuel Adekunle, Christian Couder, Samuel Abraham. Thread: https://gitlist.dev/t/65103 ## Abraham Samuel Adekunle, 2026-02-28 23:27 Subject: [GSoC] [Proposal]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/aaN5OPgoGANYlabu%40Adekunles-MacBook-Air.local ``` Hello, This is my proposal for the project "Implement promisor remote fetch ordering" for the 2026 GSoC programme. Personal Bio: ============= Full Name: Abraham Samuel Adekunle Email: abrahamadekunle50@gmail.com GitHub: https://github.com/devdekunle Pronouns: he/him About Me: ========= My name is Abraham Samuel Adekunle. I love to code, read and I am a harworker. In my free time I love to play games and listen to soothing music and well, also shifting into diffuse thinking to gain a new perspective of whatever challenge I am trying to solve. I am very curious so I really love to learn as its a never ending journey, and I believe in the power of "yet". I can understand anything, it is only a matter of time and effort. I love to figure out things and be part of a community where we can share experiences and support each other in growth. Past Experience with Git: ========================= I first learnt about Git during my ALX Software Engineering days in 2022, it proved challenging at first understanding what was going on and a git merge conflict was always a scary experience. Now I feel elated actually contributing to this renowned project. Contributions to the Git Community: ==================================== My first contribution to the Git community was during the contribution phase of the December 2024 Outreachy contribution phase where I first learned to send patches and had my first interactions with the Git code base. I did not make it through then but it was an opportunity to try again. Contributions to other Communities: =================================== I have contributed very sparingly to the Systemd project and also the Linux Kernel. Microproject: ============= Link: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/ Branch: aa/add-p-previous-decisions Status: Merged to master Commit ID: 8cafc305e22a59efb92472d4132616e24d3184c6 Description: "git add -p" and friends notes what the current status of the hunk being shown is Other Contributions: ==================== 1. Link: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/ Branch: aa/add-p-no-auto-advance Status: Merged to next Description: "git add -p" learned a new mode that allows the user to revisit a file that was already dealt with 2. Link: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/ Status: Stalled Description: the patch attempts to remove the use of the_repository global variable in some builtins Project Overview and Objective: =============================== I have always wondered what happens in the background when I see these details on my screen in a "git fetch" process. remote: Enumerating objects: 57, done. remote: Counting objects: 100% (57/57), done. remote: Compressing objects: 100% (12/12), done. Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done. Resolving deltas: 100% (21/21), done. remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30 From https://example.com/me/repo 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz And when I saw this project from the list of projects listed, I was endeared to it as it is an opportunity to work in an area of the that Git code base that will satisfy my curiousity while also being mentored by very best and most experienced Engineers there is. When a Git repository is configured with multiple promisor remotes, there is currently no mechanism to specify or optimize the order in which these remotes should be queried when fetching missing objects. Different remotes may have different performance characteristics such as characteristics, cost, or reliability which makes the fetching order an important consideration. The project aims to implement a fetch ordering mechanism for multiple promisor remotes by designing a flexible system that allows a server to dictate their preferred order to the client to ensure performance and cost management. Review of Previous Work: ======================== The project is part of the Large Object Promisor "LOP" effort documented in Documentatio/technical/large-object-promisor.adoc. In a bid to better handle large objects, the promisor-remote capability was added to the Git protocol v2, as documented in the promisor-remote section of Documentation/gitprotocol-v2.adoc, which enables a protocol negotiation so that the server can advertise one or more promisor remotes and so that the client and server can discuss if the client could directly use a promisor remote the server is advertising and if an agreement is reached, the client would be able to get the large blobs directly from the promisor remote without the server acting as a relay between the client and the promisor remote when fetching missing large blobs. The ground work for adding this capability to the v2 protocol was started by Christian Couder in [1], where if the "promisor.advertise" config is set to true, the server can then propagate its promisor remote configurations to the client over the v2 protocol during the negotiation in the form "promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2" The client can then choose to accept some promisor remotes the server is advertising using the "All", "None", "KnownName" or "KnownUrl" configurations as values for the "promisor.acceptfromServer" config option. In [2], Christian added the option for a server to advertise more fields after the "name" and "url", such as "token" and "partialCloneFilter" for the client to use this additional information in deciding the remotes to use as its promisor remotes by comparing it with its local config information. This was implemented by adding the "promisor.sendFields" and "promisor.checkFields" config values to the server and client respectively. For example, if "promisor.sendFields" is set to "partialCloneFilter", and the server has the remote configured like so: [remote "foo"] url = https://pr.test partialCloneFilter = blob:none token = "fake" then "name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake" will be advertised by the server to the client who can then decide, using the "promisor.checkFields" setting, to check if the passed field matches certain conditions before deciding to use it. This work by Christian is very crucial to this project as I will take advantage of this and enable the advertisement of a "priority" field that the server can use to communicate with the client in deciding to use the server recommended fetch order or not. in [3] Christian also implemented the option "promisor.storeFields" which allowed the value of the configuration to be saved in the client's configuration file for use at a later time. As above, this option will also prove important when the server advertises the "priority" field as it will allow the client decided to store it in its config settings for that promisor remote, for later use when fetching the remaining blobs from the promisor remotes. High Level Approach to Project Execution: ========================================= 1. Server Side Advertisement: ----------------------------- As the server knows about the promisor remotes which hold the large object blobs, it could recommend the order in which these remotes could be queried by the client using a "priority=" field of the promisor-remote capability in the Git v2 protocol, where could be an integer between 1 and 65535, where the smallest integer indicates highest priority. This will be an optional feature which will be enabled by the server if it wants to recommend ordered fetching to the client via the "promisor.sendFields=priority" config option. Hence if the server advertises promisor remotes prom1 and prom2, it could be of the form "promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20", if the server is configured as: [remote "prom1"] url = https://prom1.com priority = 10 [remote "prom2"] url = https://prom2.com priority = 20 If the "promisor.sendFields" values does not include the "priority" field in its comma or space separated options, the field will not be advertised in the promisor-remote capability. 2. Client Side Parsing: ----------------------- The client can already use the "promisor.acceptFromServer" option to decide which promisor remotes it will accept, so this new field "priority" might not be significant at all in the deciding phase but when fetching missing blobs from the accepted promisor remotes. Instead, if the client wants to use the server recommended "priority" later when fetching the missing blob from the accepted promisor remotes, the "priority" field will be added to the "promisor.storeFields" config options so that the passed value can be saved to the client config. If the client does not enable this option in the config, the "priority" field will not be saved in the local config and the fetching order will default to the local config order. A new config "promisor.honorServerFetchOrder" will be implemented on the client side to determine if the client will use the recommended server advertised promisor remote fetching order or not. This config can only be enabled if "promsior.acceptFromServer" is not "None". The options for this config value will be [true|false|local-first] where "false" (default) ignores server priority and will rely on the current config order. "true" sorts candidate advertised remotes by priority in ascending order (smallest tried first). "local-first" will try remotes in local .git/config first in the order the promisors are placed in the config file and then server advertised ones ordered by priority, if the object has not been found by now. This last values makes me feel somehow as all objects could have been fetched already but I am just stating my thought process. Proposed Project Execution Timeline: ==================================== 1. Study code base to understand promisor-remote and fetch mechanism (May 1 - 14, 2026): ------------------------------------------------------------------------------------- - Study the code base to understand how the client and server communicate using the protocol when client contacts the server. - Study how Git currently handles fetching from multiple remotes. - Set up blog for posting once a week 2. Community Bonding (May 1 - 24, 2026): ---------------------------------------- - Discuss design details with community and mentors - Understand safety, security constraints and design considerations. when implementing fetch ordering. - Read indepth the Documentations for promisor-remote, gitprotocol-v2, and other necessary documentations. - Post updates on my blog 3. Review Existing Patches (May 25 - June 14, 2026): ------------------------------- - Study Christian's patches in-depth to understand how a new field is added to the promisor remote of server, what conditions are used to ensure the data is of the right format, correctly passed from server to client, and correctly parsed and stored by client. - Understand the tests to see how these new features are tested - Post updates on my blog 4. Allow a server to add the "priority" field to the promisor-remote capability (June 14 - June 21, 2026) ------------------------------------------------------------------------------- - Discuss with mentors on the suggested approach - Allow the server to add the field "priority" to the promisor-remote capability when it is enabled in "promisor.sendFields". - Write tests to ensure proper implementation - Update documentation in Documenantation/config/promisor.adoc - Submit patch to mailing list for discussions and address reviews - Post updates on my blog 5. Allow Client to Decide to use the field (June 21 - 31, 2026): ----------------------------------------------------------------- - Discuss strategy with mentors - Allow the server to store the "priority" in its .git/config if it accepts the promisor remotes and it is included in "promisor.storeFields" - Write unit tests to ensure proper implementations - Update documentation in Documenantation/config/promisor.adoc - Submit patches to mailing list for reviews and address feedbacks - Post updates on my blog 6. Implement setting to decide fetching order: (July 1 - July 14, 2026): ------------------------------------------------------------------------ - Discuss with mentors on the approach and considerations for fetch order - Implement option "promisor.honorServerOrder" which will decide the order of fetching missing objects from the remote - Write unittests to test implementation - Update documentation in Documenantation/config/promisor.adoc - Submit patches for review and address reviews - Post updates on my blog 7. Implement fetching based on the selected order (July 15 - August 15, 2026): ------------------------------------------------------------------------------ - Implement the ordered fetching for missing objects based on the cient's configuration in 6 above. - Write unit tests to ensure the order was properly followed - Submit to mailing list and be involved in the review process - Post updates on my blog 8. Final Report on Project (August 15 - 24, 2026): -------------------------------------------------- - Document any final report in my blog with details of my experience - Finalize any pending tasks Availability: ============= I will be able to give 30 hours a week to make the project a success Post GSoC ========= Though this is not my first contribution to Git, as I have contributed very lightly to the codebase before, I am committed to continuously contributing to Git and become a part of the next set of contributors to champion the continuous development of Git. Appreciation ============ To Junio C Hamano, Phillip Wood, and everyone who helped with my patches. I really appreciate your guidance, patience and direction while reviewing and my patches. Thanks References =========== 1. https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/ 2. https://lore.kernel.org/git/20250908053056.956907-1-christian.couder@gmail.com/ 3. https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/ ``` ## Christian Couder, 2026-03-03 09:27 Subject: Re: [GSoC] [Proposal]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CAP8UFD1kzuP8sYKzTJkvf08OazrMzESQ%2BqZNW8%3DQss3DDw%3DOeA%40mail.gmail.com In-Reply-To: ``` Hi, On Sun, Mar 1, 2026 at 12:27 AM Abraham Samuel Adekunle wrote: > > Hello, > This is my proposal for the project > "Implement promisor remote fetch ordering" for the 2026 GSoC programme. Thanks for being interested in Git and this project in particular. > Personal Bio: > ============= > Full Name: Abraham Samuel Adekunle > Email: abrahamadekunle50@gmail.com > GitHub: https://github.com/devdekunle > Pronouns: he/him > > About Me: > ========= > My name is Abraham Samuel Adekunle. I love to code, read and I am a > harworker. In my free time I love to play games and listen to soothing I guess: s/harworker/hardworker/ > music and well, also shifting into diffuse thinking to gain a new > perspective of whatever challenge I am trying to solve. [...] > Contributions to the Git Community: > ==================================== > My first contribution to the Git community was during the contribution > phase of the December 2024 Outreachy contribution phase where I first > learned to send patches and had my first interactions with the Git code > base. I did not make it through then but it was an opportunity to try > again. Nice that you are trying again. > Contributions to other Communities: > =================================== > I have contributed very sparingly to the Systemd project and also > the Linux Kernel. > > Microproject: > ============= > Link: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/ > Branch: aa/add-p-previous-decisions > Status: Merged to master > Commit ID: 8cafc305e22a59efb92472d4132616e24d3184c6 > Description: "git add -p" and friends notes what the current status > of the hunk being shown is > > Other Contributions: > ==================== > 1. > Link: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/ > Branch: aa/add-p-no-auto-advance > Status: Merged to next > Description: "git add -p" learned a new mode that allows the user to > revisit a file that was already dealt with > > 2. > Link: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/ > Status: Stalled > Description: the patch attempts to remove the use of the_repository > global variable in some builtins It looks like you also have 2 contributions merged from October 2024 (when you applied for Outreachy). You can mention them too. > Project Overview and Objective: > =============================== > I have always wondered what happens in the background when I see these > details on my screen in a "git fetch" process. > > remote: Enumerating objects: 57, done. > remote: Counting objects: 100% (57/57), done. > remote: Compressing objects: 100% (12/12), done. > Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done. > Resolving deltas: 100% (21/21), done. > remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30 > From https://example.com/me/repo > 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz > > And when I saw this project from the list of projects listed, > I was endeared to it as it is an opportunity to work in an area of the > that Git code base that will satisfy my curiousity while also being s/curiousity/curiosity/ > mentored by very best and most experienced Engineers there is. > > When a Git repository is configured with multiple promisor remotes, > there is currently no mechanism to specify or optimize the order in > which these remotes should be queried when fetching missing objects. > Different remotes may have different performance characteristics > such as characteristics, cost, or reliability which makes the > fetching order an important consideration. In which order are they currently queried? > The project aims to implement a fetch ordering mechanism for multiple > promisor remotes by designing a flexible system that allows a server > to dictate their preferred order to the client to ensure performance > and cost management. A part of the whole system that allows servers to advertise information already exists and should be reused. We use "advertise" instead of "dictate" because the client should be able to decide. > Review of Previous Work: > ======================== > The project is part of the Large Object Promisor "LOP" effort > documented in Documentatio/technical/large-object-promisor.adoc. s/Documentatio/Documentation/ s/large-object-promisor/large-object-promisors/ > In a bid to better handle large objects, the promisor-remote > capability was added to the Git protocol v2, as documented in > the promisor-remote section of Documentation/gitprotocol-v2.adoc, > which enables a protocol negotiation so that the server can advertise > one or more promisor remotes and so that the client and server can > discuss if the client could directly use a promisor remote the server > is advertising and if an agreement is reached, the client would be > able to get the large blobs directly from the promisor remote without > the server acting as a relay between the client and the promisor remote when > fetching missing large blobs. > > The ground work for adding this capability to the v2 protocol was > started by Christian Couder in [1], where if the "promisor.advertise" > config is set to true, the server can then propagate its promisor remote > configurations to the client over the v2 protocol during the negotiation > in the form > > "promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2" > > The client can then choose to accept some promisor remotes the server > is advertising using the "All", "None", "KnownName" or "KnownUrl" > configurations as values for the "promisor.acceptfromServer" config option. > > In [2], Christian added the option for a server to advertise more > fields after the "name" and "url", such as "token" and > "partialCloneFilter" for the client to use this additional information > in deciding the remotes to use as its promisor remotes by comparing it > with its local config information. > > This was implemented by adding the "promisor.sendFields" and "promisor.checkFields" > config values to the server and client respectively. > For example, if "promisor.sendFields" is set to "partialCloneFilter", and the > server has the remote configured like so: > [remote "foo"] > url = https://pr.test > partialCloneFilter = blob:none > token = "fake" > then > "name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake" > will be advertised by the server to the client who can then decide, > using the "promisor.checkFields" setting, to check if the passed field > matches certain conditions before deciding to use it. > > This work by Christian is very crucial to this project as I will take > advantage of this and enable the advertisement of a "priority" field > that the server can use to communicate with the client in deciding to > use the server recommended fetch order or not. > > in [3] Christian also implemented the option "promisor.storeFields" which > allowed the value of the configuration to be saved in the client's > configuration file for use at a later time. > As above, this option will also prove important when the server advertises > the "priority" field as it will allow the client decided to store it in its > config settings for that promisor remote, for later use when fetching > the remaining blobs from the promisor remotes. Yeah, this is about allowing the server to advertise priority information, and the client to accept it or not, but this doesn't talk much about how this information will be used to actually change the fetch order. It would be nice if this could talk about which order is currently used. You might want to take a look at Documentation/technical/partial-clone.adoc, especially the "Using many promisor remotes" section. > High Level Approach to Project Execution: > ========================================= > 1. Server Side Advertisement: > ----------------------------- > As the server knows about the promisor remotes which hold the > large object blobs, First I would say "large blob objects" or just "large blobs" instead of "large object blobs" if I wanted to talk about them. Then it's true that the "promisor-remote" capability in protocol v2 was developed especially to help with large blobs and the LOP effort, but this GSoC project could be useful for any partial clone that uses multiple promisor remotes. So you could talk about "objects", not just "large blobs". > it could recommend the order in which these remotes > could be queried by the client using a "priority=" field of the > promisor-remote capability in the Git v2 protocol, where could > be an integer between 1 and 65535, where the smallest integer indicates > highest priority. > > This will be an optional feature which will be enabled by the server > if it wants to recommend ordered fetching to the client via > the "promisor.sendFields=priority" config option. > > Hence if the server advertises promisor remotes prom1 and prom2, > it could be of the form > "promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20", > if the server is configured as: > [remote "prom1"] > url = https://prom1.com > priority = 10 > [remote "prom2"] > url = https://prom2.com > priority = 20 > > If the "promisor.sendFields" values does not include the "priority" > field in its comma or space separated options, the field will not be > advertised in the promisor-remote capability. The issue is that right now "priority = 10" or "priority = 20" if they were configured would change nothing in the order used to fetch from promisor remotes. So the first thing to do (before having the server send that and the client use it or not) is to actually introduce the `remote..priority` config option and make it change the fetch order. When that works, it makes sense to allow the server to advertise it, and the client to accept it or not from the server. > 2. Client Side Parsing: > ----------------------- > The client can already use the "promisor.acceptFromServer" option to > decide which promisor remotes it will accept, so this new field > "priority" might not be significant at all in the deciding phase but when > fetching missing blobs from the accepted promisor remotes. If that's what you mean, I agree that the priority advertised by a server for a promisor remote is not likely to be a (good) criteria on the client side to help decide if the client accepts to use the promisor remote or not. You might want to reword the above paragraph though as it's not easy to understand. > Instead, if the client wants to use the server recommended "priority" > later when fetching the missing blob from the accepted promisor remotes, > the "priority" field will be added to the "promisor.storeFields" config > options so that the passed value can be saved to the client config. Yeah, that's the most likely way the client would use it. > If the client does not enable this option in the config, the "priority" > field will not be saved in the local config and the fetching order will > default to the local config order. Right. > A new config "promisor.honorServerFetchOrder" will be implemented > on the client side to determine if the client will use the recommended > server advertised promisor remote fetching order or not. I don't think this is necessary. If the client doesn't want to use the priority advertised by the server, it just needs to not add "priority" to the "promisor.storeFields" config variable. > This config can only be enabled if "promsior.acceptFromServer" is not > "None". > > The options for this config value will be [true|false|local-first] where > "false" (default) ignores server priority and will rely on the current > config order. > "true" sorts candidate advertised remotes by priority in ascending > order (smallest tried first). > "local-first" will try remotes in local .git/config first in the order > the promisors are placed in the config file and then > server advertised ones ordered by priority, if the object has not been > found by now. This last values makes me feel somehow as all objects s/values/value/ > could have been fetched already but I am just stating my thought process. I think we will likely not need something like this. The 3 different possibilities could be configured this way: - to rely on the order advertised by the server: just add "priority" to "promisor.storeFields" - to rely on local "priority" config: just add "priority = XXX" to some/all "remote." - to rely on the default order: add nothing > Proposed Project Execution Timeline: > ==================================== This needs to take into account that the first step should be to actually introduce the `remote..priority` config option and make it change the fetch order. Thanks. ``` ## Samuel Abraham, 2026-03-03 12:08 Subject: Re: [GSoC] [Proposal]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CADYq%2BfYf0%2BCYSs8j54WhhrE_%3Dk%2BdtvznwWTcpX24f6wt4nL0ow%40mail.gmail.com In-Reply-To: ``` On Tue, Mar 3, 2026 at 10:27 AM Christian Couder wrote: > > Hi, > > On Sun, Mar 1, 2026 at 12:27 AM Abraham Samuel Adekunle > wrote: > > > > Hello, > > This is my proposal for the project > > "Implement promisor remote fetch ordering" for the 2026 GSoC programme. > > Thanks for being interested in Git and this project in particular. Thank you. > > > Personal Bio: > > ============= > > Full Name: Abraham Samuel Adekunle > > Email: abrahamadekunle50@gmail.com > > GitHub: https://github.com/devdekunle > > Pronouns: he/him > > > > About Me: > > ========= > > My name is Abraham Samuel Adekunle. I love to code, read and I am a > > harworker. In my free time I love to play games and listen to soothing > > I guess: s/harworker/hardworker/ Okay I will fix it > > > music and well, also shifting into diffuse thinking to gain a new > > perspective of whatever challenge I am trying to solve. > > [...] > > > Contributions to the Git Community: > > ==================================== > > My first contribution to the Git community was during the contribution > > phase of the December 2024 Outreachy contribution phase where I first > > learned to send patches and had my first interactions with the Git code > > base. I did not make it through then but it was an opportunity to try > > again. > > Nice that you are trying again. Thank you :) > > > Contributions to other Communities: > > =================================== > > I have contributed very sparingly to the Systemd project and also > > the Linux Kernel. > > > > Microproject: > > ============= > > Link: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/ > > Branch: aa/add-p-previous-decisions > > Status: Merged to master > > Commit ID: 8cafc305e22a59efb92472d4132616e24d3184c6 > > Description: "git add -p" and friends notes what the current status > > of the hunk being shown is > > > > Other Contributions: > > ==================== > > 1. > > Link: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/ > > Branch: aa/add-p-no-auto-advance > > Status: Merged to next > > Description: "git add -p" learned a new mode that allows the user to > > revisit a file that was already dealt with > > > > 2. > > Link: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/ > > Status: Stalled > > Description: the patch attempts to remove the use of the_repository > > global variable in some builtins > > It looks like you also have 2 contributions merged from October 2024 > (when you applied for Outreachy). You can mention them too. Okay I will do that. > > > Project Overview and Objective: > > =============================== > > I have always wondered what happens in the background when I see these > > details on my screen in a "git fetch" process. > > > > remote: Enumerating objects: 57, done. > > remote: Counting objects: 100% (57/57), done. > > remote: Compressing objects: 100% (12/12), done. > > Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done. > > Resolving deltas: 100% (21/21), done. > > remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30 > > From https://example.com/me/repo > > 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz > > > > And when I saw this project from the list of projects listed, > > I was endeared to it as it is an opportunity to work in an area of the > > that Git code base that will satisfy my curiousity while also being > > s/curiousity/curiosity/ Thanks > > > mentored by very best and most experienced Engineers there is. > > > > When a Git repository is configured with multiple promisor remotes, > > there is currently no mechanism to specify or optimize the order in > > which these remotes should be queried when fetching missing objects. > > Different remotes may have different performance characteristics > > such as characteristics, cost, or reliability which makes the > > fetching order an important consideration. > > In which order are they currently queried? In the order they appear in the config file, with promisor remote configured with the extensions.partialClone (most likely "origin") bring the last one tried. > > > The project aims to implement a fetch ordering mechanism for multiple > > promisor remotes by designing a flexible system that allows a server > > to dictate their preferred order to the client to ensure performance > > and cost management. > > A part of the whole system that allows servers to advertise > information already exists and should be reused. > > We use "advertise" instead of "dictate" because the client should be > able to decide. I will reword it. Thanks > > > Review of Previous Work: > > ======================== > > The project is part of the Large Object Promisor "LOP" effort > > documented in Documentatio/technical/large-object-promisor.adoc. > > s/Documentatio/Documentation/ > s/large-object-promisor/large-object-promisors/ Thank you > > > In a bid to better handle large objects, the promisor-remote > > capability was added to the Git protocol v2, as documented in > > the promisor-remote section of Documentation/gitprotocol-v2.adoc, > > which enables a protocol negotiation so that the server can advertise > > one or more promisor remotes and so that the client and server can > > discuss if the client could directly use a promisor remote the server > > is advertising and if an agreement is reached, the client would be > > able to get the large blobs directly from the promisor remote without > > the server acting as a relay between the client and the promisor remote when > > fetching missing large blobs. > > > > The ground work for adding this capability to the v2 protocol was > > started by Christian Couder in [1], where if the "promisor.advertise" > > config is set to true, the server can then propagate its promisor remote > > configurations to the client over the v2 protocol during the negotiation > > in the form > > > > "promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2" > > > > The client can then choose to accept some promisor remotes the server > > is advertising using the "All", "None", "KnownName" or "KnownUrl" > > configurations as values for the "promisor.acceptfromServer" config option. > > > > In [2], Christian added the option for a server to advertise more > > fields after the "name" and "url", such as "token" and > > "partialCloneFilter" for the client to use this additional information > > in deciding the remotes to use as its promisor remotes by comparing it > > with its local config information. > > > > This was implemented by adding the "promisor.sendFields" and "promisor.checkFields" > > config values to the server and client respectively. > > For example, if "promisor.sendFields" is set to "partialCloneFilter", and the > > server has the remote configured like so: > > [remote "foo"] > > url = https://pr.test > > partialCloneFilter = blob:none > > token = "fake" > > then > > "name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake" > > will be advertised by the server to the client who can then decide, > > using the "promisor.checkFields" setting, to check if the passed field > > matches certain conditions before deciding to use it. > > > > This work by Christian is very crucial to this project as I will take > > advantage of this and enable the advertisement of a "priority" field > > that the server can use to communicate with the client in deciding to > > use the server recommended fetch order or not. > > > > in [3] Christian also implemented the option "promisor.storeFields" which > > allowed the value of the configuration to be saved in the client's > > configuration file for use at a later time. > > As above, this option will also prove important when the server advertises > > the "priority" field as it will allow the client decided to store it in its > > config settings for that promisor remote, for later use when fetching > > the remaining blobs from the promisor remotes. > > Yeah, this is about allowing the server to advertise priority > information, and the client to accept it or not, but this doesn't talk > much about how this information will be used to actually change the > fetch order. > > It would be nice if this could talk about which order is currently > used. You might want to take a look at > Documentation/technical/partial-clone.adoc, especially the "Using many > promisor remotes" section. Okay thank you. I will add that to the v2. > > > High Level Approach to Project Execution: > > ========================================= > > 1. Server Side Advertisement: > > ----------------------------- > > As the server knows about the promisor remotes which hold the > > large object blobs, > > First I would say "large blob objects" or just "large blobs" instead > of "large object blobs" if I wanted to talk about them. Okay thank you > > Then it's true that the "promisor-remote" capability in protocol v2 > was developed especially to help with large blobs and the LOP effort, > but this GSoC project could be useful for any partial clone that uses > multiple promisor remotes. So you could talk about "objects", not just > "large blobs". Okay Noted > > > it could recommend the order in which these remotes > > could be queried by the client using a "priority=" field of the > > promisor-remote capability in the Git v2 protocol, where could > > be an integer between 1 and 65535, where the smallest integer indicates > > highest priority. > > > > This will be an optional feature which will be enabled by the server > > if it wants to recommend ordered fetching to the client via > > the "promisor.sendFields=priority" config option. > > > > Hence if the server advertises promisor remotes prom1 and prom2, > > it could be of the form > > "promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20", > > if the server is configured as: > > [remote "prom1"] > > url = https://prom1.com > > priority = 10 > > [remote "prom2"] > > url = https://prom2.com > > priority = 20 > > > > If the "promisor.sendFields" values does not include the "priority" > > field in its comma or space separated options, the field will not be > > advertised in the promisor-remote capability. > > The issue is that right now "priority = 10" or "priority = 20" if they > were configured would change nothing in the order used to fetch from > promisor remotes. So the first thing to do (before having the server > send that and the client use it or not) is to actually introduce the > `remote..priority` config option and make it change the fetch > order. When that works, it makes sense to allow the server to > advertise it, and the client to accept it or not from the server. Yes thank you. I will fix this in the v2 > > > 2. Client Side Parsing: > > ----------------------- > > The client can already use the "promisor.acceptFromServer" option to > > decide which promisor remotes it will accept, so this new field > > "priority" might not be significant at all in the deciding phase but when > > fetching missing blobs from the accepted promisor remotes. > > If that's what you mean, I agree that the priority advertised by a > server for a promisor remote is not likely to be a (good) criteria on > the client side to help decide if the client accepts to use the > promisor remote or not. You might want to reword the above paragraph > though as it's not easy to understand. Okay > > > Instead, if the client wants to use the server recommended "priority" > > later when fetching the missing blob from the accepted promisor remotes, > > the "priority" field will be added to the "promisor.storeFields" config > > options so that the passed value can be saved to the client config. > > Yeah, that's the most likely way the client would use it. > > > If the client does not enable this option in the config, the "priority" > > field will not be saved in the local config and the fetching order will > > default to the local config order. > > Right. > > > A new config "promisor.honorServerFetchOrder" will be implemented > > on the client side to determine if the client will use the recommended > > server advertised promisor remote fetching order or not. > > I don't think this is necessary. If the client doesn't want to use the > priority advertised by the server, it just needs to not add "priority" > to the "promisor.storeFields" config variable. Okay thank you > > > This config can only be enabled if "promsior.acceptFromServer" is not > > "None". > > > > The options for this config value will be [true|false|local-first] where > > "false" (default) ignores server priority and will rely on the current > > config order. > > "true" sorts candidate advertised remotes by priority in ascending > > order (smallest tried first). > > "local-first" will try remotes in local .git/config first in the order > > the promisors are placed in the config file and then > > server advertised ones ordered by priority, if the object has not been > > found by now. This last values makes me feel somehow as all objects > > s/values/value/ > > > could have been fetched already but I am just stating my thought process. > > I think we will likely not need something like this. The 3 different > possibilities could be configured this way: > > - to rely on the order advertised by the server: just add "priority" > to "promisor.storeFields" > - to rely on local "priority" config: just add "priority = XXX" to > some/all "remote." > - to rely on the default order: add nothing Thank you for the guidance. I will fix all the changes in the v2 > > > Proposed Project Execution Timeline: > > ==================================== > > This needs to take into account that the first step should be to > actually introduce the `remote..priority` config option and make > it change the fetch order. Yes Thank you for the review. Abraham ``` ## Abraham Samuel Adekunle, 2026-03-04 07:35 Subject: [GSoC] [Proposal v2]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/aafga8AjpxagiEJt%40Adekunles-MacBook-Air.local In-Reply-To: ``` Hello, This is the second iteration of my proposal for the project "Implement promisor remote fetch ordering" for the 2026 GSoC programme. Personal Bio: ============= Full Name: Abraham Samuel Adekunle Email: abrahamadekunle50@gmail.com GitHub: https://github.com/devdekunle Pronouns: he/him About Me: ========= My name is Abraham Samuel Adekunle. I love to code, read and I am a hard worker. In my free time I love to play games and listen to soothing music and well, also shift into diffuse thinking to gain a new perspective of whatever challenge I am trying to solve. I am very curious so I really love to learn as it's a never ending journey, and I believe in the power of "yet". I can understand anything, it is only a matter of time and effort. I love to figure out things and be part of a community where we can share experiences and support each other in growth. Past Experience with Git: ========================= I first learnt about Git during my ALX Software Engineering days in 2022, it proved challenging at first understanding what was going on and a git merge conflict was always a scary experience. Now I feel elated actually contributing to this renowned project. Contributions to the Git Community: ==================================== My first contribution to the Git community was during the contribution phase of the December 2024 Outreachy contribution phase where I first learned to send patches and had my first interactions with the Git code base. I did not make it through then but it was an opportunity to try again. Contributions to other Communities: =================================== I have contributed very sparingly to the Systemd project and also the Linux Kernel. Microproject: ============= Link: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/ Branch: aa/add-p-previous-decisions Status: Merged to master Commit ID: 8cafc305e22a59efb92472d4132616e24d3184c6 Description: "git add -p" and friends notes what the current status of the hunk being shown is Other Contributions: ==================== 1. Link: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/ Branch: aa/add-p-no-auto-advance Status: Will merge to master Description: "git add -p" learned a new mode that allows the user to revisit a file that was already dealt with 2. Link: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/ Status: Stalled Description: the patch attempts to remove the use of the_repository global variable in some builtins 3. Link: https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@gmail.com/ Branch: sa/notes-edit Status: Merged to master Description: Teach 'git notes add' and 'git notes append' a new '-e' flag, instructing them to open the note in $GIT_EDITOR before saving. 4. Link: https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@gmail.com/ Branch: aa/t7300-modernize Status: Merged to master Description: use test_path_* helper functions for error logging Project Overview and Objective: =============================== I have always wondered what happens in the background when I see these details on my screen in a "git fetch" process. remote: Enumerating objects: 57, done. remote: Counting objects: 100% (57/57), done. remote: Compressing objects: 100% (12/12), done. Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done. Resolving deltas: 100% (21/21), done. remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30 From https://example.com/me/repo 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz And when I saw this project from the list of projects listed, I was endeared to it as it is an opportunity to work in an area of the that Git code base that will satisfy my curiosity while also being mentored by very best and most experienced Engineers there is. When a Git repository is configured with multiple promisor remotes, there is currently no other mechanism to specify or optimize the order in which these remotes should be queried when fetching missing objects. Different remotes may have different performance characteristics such as characteristics, cost, or reliability which makes the fetching order an important consideration. Currently, the promisor remotes are queried in the order in which they appear in the local .git/config. The project aims to implement a fetch ordering mechanism for multiple promisor remotes that allows a client to be able to specify a fetching order, a server to advertise an order to the client to ensure performance and cost management, and the client to decide to use the server advertised order or not, and default to the current order if no order is specified. Review of Previous Work: ======================== The project is part of the Large Object Promisor "LOP" effort documented in Documentation/technical/large-object-promisors.adoc. In a bid to better handle large objects, the promisor-remote capability was added to the Git protocol v2, as documented in the promisor-remote section of Documentation/gitprotocol-v2.adoc, which enables a protocol negotiation so that the server can advertise one or more promisor remotes and so that the client and server can discuss if the client could directly use a promisor remote the server is advertising and if an agreement is reached, the client would be able to get the missing objects directly from the promisor remote without the server acting as a relay between the client and the promisor remote when fetching missing objects. The ground work for adding this capability to the v2 protocol was started by Christian Couder in [1], where if the "promisor.advertise" config is set to true, the server can then propagate its promisor remote configurations to the client over the v2 protocol during the negotiation in the form "promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2" The client can then choose to accept some promisor remotes the server is advertising using the "All", "None", "KnownName" or "KnownUrl" configurations as values for the "promisor.acceptfromServer" config option. In [2], Christian added the option for a server to advertise more fields after the "name" and "url", such as "token" and "partialCloneFilter" for the client to use this additional information in deciding the remotes to use as its promisor remotes by comparing it with its local config information. This was implemented by adding the "promisor.sendFields" and "promisor.checkFields" config values to the server and client respectively. For example, if "promisor.sendFields" is set to "partialCloneFilter", and the server has the remote configured like so: [remote "foo"] url = https://pr.test partialCloneFilter = blob:none token = "fake" then "name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake" will be advertised by the server to the client who can then decide, using the "promisor.checkFields" setting, to check if the passed field matches certain conditions before deciding to use it. This work by Christian is very crucial to this project as I will take advantage of this and enable the advertisement of a "priority" field that the server can use to communicate with the client in deciding to use the server recommended fetch order or not. in [3] Christian also implemented the option "promisor.storeFields" which allowed the value of the configuration to be saved in the client's configuration file for use at a later time. As above, this option will also prove important when the server advertises the "priority" field as it will allow the client decided to store it in its config settings for that promisor remote, for later use when fetching the remaining blobs from the promisor remotes. As documented in Documentation/technical/partial-clone.adoc, when using multiple promisor remotes, currently, the promisor remotes are tried in the order in which they appear in the config file with the promisor remote configured with "extension.partialClone" being the last one tried. As the goal of this project is to implement a fetch order when fetching the missing objects, I would take advantage of the ground work done by Christian by adding a "priority" field to the promisor-remote capability when "priority" is added to the "promisor.sendFields" server config option, which indicates that the server is recommending the client to use the fetch order. If the client chooses to use the server recommended fetch order, it can add "priority" to the "promisor.storeFields" config option which will store this values and query the promisor remotes in that order. If the client choose to ignore this recommendation, it can simply choose not to store it and instead use its own preferred order by setting the priority for some or all the remotes to its preferred value and this will query the objects in that order. Not using either of this order will query the promisor remotes in the current default order. High Level Approach to Project Execution: ========================================= 1. Introduce the `remote..priority` config option: ====================================================== As said above, when fetching missing objects, the order in which the remotes are queried depends on the order in which they appear in the config file. To make this flexible, I will introduce the `remote..priority` config option, which will allow the client to set its preferred fetch order to each promisor remote configuration, and then make it fetch based on this "priority" order. The value of this option could be an integer between 1 and 65535, where the smallest integer indicates highest priority. This will allow a promisor remote be configured as follows [remote "prom1"] url = https://prom1.com priority = 10 Therefore when the client is configured with more than one promisor remote and the prority is set for each promisor remote as follows, [remote "prom1"] url = https://prom1.com priority = 20 [remote "prom2"] url = https://prom2.com priority = 10, when fetching for the missing objects, the promisor remote "prom2" will be queried first before "prom1". 2. Server Side Advertisement: ----------------------------- After the `remote..priority` config option has been implemented and the fetch order can be changed, I will then allow the server to advertise its recommended fetch order in the promisor-remote capability. As the server knows about the promisor remotes which hold the missing objects, it could recommend the order in which these remotes could be queried by the client using a "priority=" field of the promisor-remote capability in the Git v2 protocol, where could be an integer between 1 and 65535, and the smallest integer indicates highest priority. This will be an optional feature which will be enabled by the server if it wants to recommend ordered fetching to the client via the "promisor.sendFields=priority" config option. Hence if the server advertises promisor remotes prom1 and prom2, it could be of the form "promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20", if the server is configured as: [remote "prom1"] url = https://prom1.com priority = 10 [remote "prom2"] url = https://prom2.com priority = 20 If the "promisor.sendFields" values does not include the "priority" field in its comma or space separated options, the field will not be advertised in the promisor-remote capability. 3. Client Side Parsing: ----------------------- After the "priority" field has been advertised in the promisor-remote capability, the client can choose to use this server recommended fetch order or ignore it completely. If the client wants to use the server recommended fetch order later when fetching the missing objects from the accepted promisor remotes, the "priority" field will be added to the "promisor.storeFields" config options so that the passed value can be saved to the client config. If the client does not enable this option in the config, the "priority" field will not be saved in the local config and the fetching order will be client specified order if set or the default local config order if not set. The three different fetch order are; 1. the order advertised by the server, where the "priority" field will be added to "promisor.storeFields" and the value will be saved to the local config file for the selected promisor remotes. When fetching the missing objects, this order will be used. 2. the local "priority" config where the client can set the "priority" field using, priority=, of some or all "remote." to indicate its preferred fetch order when fetching the missing objects. This order will be used if the "promisor.storeFields" does not include the "priority" field. 3. the default order, where the field will not be added to the config and hence the current default order will be used. Proposed Project Execution Timeline: ==================================== 1. Study code base to understand promisor-remote and fetch mechanism (May 1 - 14, 2026): ------------------------------------------------------------------------------------- - Study the code base to understand how the client and server communicate using the protocol when client contacts the server. - Study how Git currently handles fetching from multiple remotes. - Set up blog for posting once in two weeks 2. Community Bonding (May 1 - 14, 2026): ---------------------------------------- - Discuss design details with community and mentors - Understand safety, security constraints and design considerations when implementing fetch ordering. - Read indepth the Documentations for promisor-remote, gitprotocol-v2, and other necessary documentations. - Post updates on my blog 3. Review Existing Patches and related code (May 15 - May 25, 2026): ------------------------------- - Study code base to understand how a new config option is added. - study code that handles the fetching of missing objects after a partial clone/fetch. - Study Christian's patches in-depth to understand how a new field is added to the promisor remote of server, what conditions are used to ensure the data is of the right format, correctly passed from server to client, and correctly parsed and stored by client. - Study how a client can store the new field it accepts to use from the advertised fields. - Understand the tests to see how these new features are tested - Post updates on my blog 4. Introduce the `remote..priority` config option: (May 25 - June 13, 2026): ------------------------------------------------------- - Discuss with mentors on the suggested approach - Allow the addition of the config option `remote..priority` - Implement fetching based on this option when set by the client and if not set, default to the current order. - Write tests to ensure proper implementation of the new config and fetch order - Submit patches to mailing list and engage in reviews with Community members - Post update on my blog 5. Allow a server to add the "priority" field to the promisor-remote capability (June 14 - June 21, 2026) ------------------------------------------------------------------------------- - Discuss with mentors on the suggested approach - Allow the server to add the field "priority" to the promisor-remote capability when it is enabled in "promisor.sendFields". - Write tests to ensure proper implementation - Update documentation in Documenantation/config/promisor.adoc - Submit patch to mailing list for discussions and address reviews - Post updates on my blog 6. Allow Client to decide to use the field (June 21 - 14, 2026): ----------------------------------------------------------------- - Discuss strategy with mentors - Allow the client to store the "priority" in its .git/config if it accepts the promisor remotes and it is included in "promisor.storeFields" - Write unit tests to ensure proper implementations - Update documentation in Documentation/config/promisor.adoc - Submit patches to mailing list for reviews and address feedbacks - Post updates on my blog 7. Implement fetching order based on setting: (July 15 - August 14, 2026): ------------------------------------------------------------------------ - Discuss with mentors on the approach and considerations for fetch order - Implement fetching based on the client's accepted fetching order - Write unittests to test implementation - Update documentation in Documenantation/config/promisor.adoc - Submit patches for review and address reviews - Post updates on my blog 9. Final Report on Project (August 15 - 24, 2026): -------------------------------------------------- - Document any final report in my blog with details of my experience - Finalize any pending tasks Availability: ============= I will be able to give 30 hours a week to make the project a success Post GSoC ========= Though this is not my first contribution to Git, as I have contributed very lightly to the codebase before, I am committed to continuously contributing to Git and become a part of the next set of contributors to champion the continuous development of Git. Appreciation ============ To Junio C Hamano, Phillip Wood, and everyone who helped with my patches. I really appreciate your guidance, patience and direction while reviewing and my patches. Thanks References =========== 1. https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/ 2. https://lore.kernel.org/git/20250908053056.956907-1-christian.couder@gmail.com/ 3. https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/ ``` ## Samuel Abraham, 2026-03-10 15:11 Subject: Re: [GSoC] [Proposal]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CADYq%2BfbDVWNfomJ-UEU0QsEAmHoS9pa03aW5wOjBTyQfD2ojHQ%40mail.gmail.com In-Reply-To: ``` On Tue, Mar 3, 2026 at 10:27 AM Christian Couder wrote: > > Hi, > > On Sun, Mar 1, 2026 at 12:27 AM Abraham Samuel Adekunle > wrote: > > > > Hello, > > This is my proposal for the project > > "Implement promisor remote fetch ordering" for the 2026 GSoC programme. > > Thanks for being interested in Git and this project in particular. > Hello Christian. Thank you for taking out time to review my proposal. I have made your recommended changes and sent a v2. Thanks Abraham ``` ## Samuel Abraham, 2026-03-17 07:53 Subject: Re: [GSoC] [Proposal v2]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CADYq%2Bfb%2BMdpUTgLbcfoh380jiXi8HCZZbKaxgZDtb-rxrxC9zg%40mail.gmail.com In-Reply-To: ``` On Wed, Mar 4, 2026 at 8:35 AM Abraham Samuel Adekunle wrote: > > Hello, > This is the second iteration of my proposal for the project > "Implement promisor remote fetch ordering" for the 2026 GSoC programme. > > Personal Bio: > ============= > Full Name: Abraham Samuel Adekunle > Email: abrahamadekunle50@gmail.com > GitHub: https://github.com/devdekunle > Pronouns: he/him > Hello, Just bumping this up to get reviews for my GSoC proposal v2. Thanks Abraham ``` ## Christian Couder, 2026-03-24 12:29 Subject: Re: [GSoC] [Proposal v2]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CAP8UFD16pvfP4UYJHCCenK3c1-VNTJPpMBJL_LnHZZZXUC5ULA%40mail.gmail.com In-Reply-To: ``` Hi, On Wed, Mar 4, 2026 at 8:35 AM Abraham Samuel Adekunle wrote: > When a Git repository is configured with multiple promisor remotes, > there is currently no other mechanism to specify or optimize the order in > which these remotes should be queried when fetching missing objects. > Different remotes may have different performance characteristics > such as characteristics, cost, or reliability which makes the There is a repetition of "characteristics" above. > fetching order an important consideration. > Currently, the promisor remotes are queried in the order in which they > appear in the local .git/config. There is the exception of the `extensions.partialClone` config variable. Also I recently sent a patch series that might change things (see the first patch in the series introduced by https://lore.kernel.org/git/20260323080520.887550-1-christian.couder@gmail.com/), but it's not merged, so don't rewrite your proposal to take it into account. > The project aims to implement a fetch ordering mechanism for multiple > promisor remotes that allows a client to be able to specify a fetching order, > a server to advertise an order to the client to ensure performance > and cost management, and the client to decide to use the server advertised > order or not, and default to the current order if no order is specified. > > Review of Previous Work: > ======================== > The project is part of the Large Object Promisor "LOP" effort > documented in Documentation/technical/large-object-promisors.adoc. > > In a bid to better handle large objects, the promisor-remote > capability was added to the Git protocol v2, as documented in > the promisor-remote section of Documentation/gitprotocol-v2.adoc, > which enables a protocol negotiation so that the server can advertise > one or more promisor remotes and so that the client and server can > discuss if the client could directly use a promisor remote the server > is advertising and if an agreement is reached, the client would be > able to get the missing objects directly from the promisor remote without > the server acting as a relay between the client and the promisor remote when > fetching missing objects. You might want to split this very long sentence into a few smaller ones. > The ground work for adding this capability to the v2 protocol was > started by Christian Couder in [1], where if the "promisor.advertise" > config is set to true, the server can then propagate its promisor remote > configurations to the client over the v2 protocol during the negotiation > in the form > > "promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2" > > The client can then choose to accept some promisor remotes the server > is advertising using the "All", "None", "KnownName" or "KnownUrl" > configurations as values for the "promisor.acceptfromServer" config option. > > In [2], Christian added the option for a server to advertise more > fields after the "name" and "url", such as "token" and > "partialCloneFilter" for the client to use this additional information > in deciding the remotes to use as its promisor remotes by comparing it > with its local config information. > > This was implemented by adding the "promisor.sendFields" and > "promisor.checkFields" config values to the server and client respectively. > For example, if "promisor.sendFields" is set to "partialCloneFilter", and the > server has the remote configured like so: > [remote "foo"] > url = https://pr.test > partialCloneFilter = blob:none > token = "fake" > then > > "name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake" > will be advertised by the server to the client who can then decide, > using the "promisor.checkFields" setting, to check if the passed field > matches certain conditions before deciding to use it. The "promisor.checkFields" config variable is not quite to decide if fields can be used, but more to decide if they should be checked before the remote is accepted. Using the "promisor.storeFields" config option is better if fields should be used. > This work by Christian is very crucial to this project as I will take > advantage of this and enable the advertisement of a "priority" field > that the server can use to communicate with the client in deciding to > use the server recommended fetch order or not. > > in [3] Christian also implemented the option "promisor.storeFields" which > allowed the value of the configuration to be saved in the client's > configuration file for use at a later time. > As above, this option will also prove important when the server advertises > the "priority" field as it will allow the client decided to store it in its Maybe: s/decided // > config settings for that promisor remote, for later use when fetching > the remaining blobs from the promisor remotes. Yes. [...] > High Level Approach to Project Execution: > ========================================= > > 1. Introduce the `remote..priority` config option: > ====================================================== > As said above, when fetching missing objects, the order in which the remotes > are queried depends on the order in which they appear in the config file. Not sure this is worth repeating three times. > To make this flexible, I will introduce the `remote..priority` config option, > which will allow the client to set its preferred fetch order to each promisor remote > configuration, and then make it fetch based on this "priority" order. > The value of this option could be an integer between 1 and 65535, where the smallest Why 65535? > integer indicates highest priority. > > This will allow a promisor remote be configured as follows > > [remote "prom1"] > url = https://prom1.com > priority = 10 > > Therefore when the client is configured with more than one promisor remote > and the prority is set for each promisor remote as follows, s/prority/priority/ > [remote "prom1"] > url = https://prom1.com > priority = 20 > [remote "prom2"] > url = https://prom2.com > priority = 10, [...] > 2. Community Bonding (May 1 - 14, 2026): > ---------------------------------------- > - Discuss design details with community and mentors > - Understand safety, security constraints and design considerations > when implementing fetch ordering. > - Read indepth the Documentations for promisor-remote, gitprotocol-v2, s/indepth/in depth/ > and other necessary documentations. Thanks. ``` ## Samuel Abraham, 2026-03-24 15:58 Subject: Re: [GSoC] [Proposal v2]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CADYq%2BfZfaFyOd%2B%2BwT3gTbMNxT7ArGEzmYc09ydOHuSAnu5QcFw%40mail.gmail.com In-Reply-To: ``` On Tue, Mar 24, 2026 at 1:29 PM Christian Couder wrote: > > Hi, > > On Wed, Mar 4, 2026 at 8:35 AM Abraham Samuel Adekunle > wrote: > > > When a Git repository is configured with multiple promisor remotes, > > there is currently no other mechanism to specify or optimize the order in > > which these remotes should be queried when fetching missing objects. > > Different remotes may have different performance characteristics > > such as characteristics, cost, or reliability which makes the > > There is a repetition of "characteristics" above. Oh thanks > > > fetching order an important consideration. > > Currently, the promisor remotes are queried in the order in which they > > appear in the local .git/config. > > There is the exception of the `extensions.partialClone` config variable. Yes, I stated it below. I will probably bring the statement here. > > Also I recently sent a patch series that might change things (see the > first patch in the series introduced by > https://lore.kernel.org/git/20260323080520.887550-1-christian.couder@gmail.com/), > but it's not merged, so don't rewrite your proposal to take it into > account. Yes, I took a brief look when you submitted it to the mailing list yesterday. Thanks and well done Christian, I will keep up with the series. > > > The project aims to implement a fetch ordering mechanism for multiple > > promisor remotes that allows a client to be able to specify a fetching order, > > a server to advertise an order to the client to ensure performance > > and cost management, and the client to decide to use the server advertised > > order or not, and default to the current order if no order is specified. > > > > Review of Previous Work: > > ======================== > > The project is part of the Large Object Promisor "LOP" effort > > documented in Documentation/technical/large-object-promisors.adoc. > > > > In a bid to better handle large objects, the promisor-remote > > capability was added to the Git protocol v2, as documented in > > the promisor-remote section of Documentation/gitprotocol-v2.adoc, > > which enables a protocol negotiation so that the server can advertise > > one or more promisor remotes and so that the client and server can > > discuss if the client could directly use a promisor remote the server > > is advertising and if an agreement is reached, the client would be > > able to get the missing objects directly from the promisor remote without > > the server acting as a relay between the client and the promisor remote when > > fetching missing objects. > > You might want to split this very long sentence into a few smaller ones. Okay I will. > > > The ground work for adding this capability to the v2 protocol was > > started by Christian Couder in [1], where if the "promisor.advertise" > > config is set to true, the server can then propagate its promisor remote > > configurations to the client over the v2 protocol during the negotiation > > in the form > > > > "promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2" > > > > The client can then choose to accept some promisor remotes the server > > is advertising using the "All", "None", "KnownName" or "KnownUrl" > > configurations as values for the "promisor.acceptfromServer" config option. > > > > In [2], Christian added the option for a server to advertise more > > fields after the "name" and "url", such as "token" and > > "partialCloneFilter" for the client to use this additional information > > in deciding the remotes to use as its promisor remotes by comparing it > > with its local config information. > > > > This was implemented by adding the "promisor.sendFields" and > > "promisor.checkFields" config values to the server and client respectively. > > For example, if "promisor.sendFields" is set to "partialCloneFilter", and the > > server has the remote configured like so: > > [remote "foo"] > > url = https://pr.test > > partialCloneFilter = blob:none > > token = "fake" > > then > > > > "name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake" > > will be advertised by the server to the client who can then decide, > > using the "promisor.checkFields" setting, to check if the passed field > > matches certain conditions before deciding to use it. > > The "promisor.checkFields" config variable is not quite to decide if > fields can be used, but more to decide if they should be checked > before the remote is accepted. Okay thanks. > > Using the "promisor.storeFields" config option is better if fields > should be used. Yes thanks > > > This work by Christian is very crucial to this project as I will take > > advantage of this and enable the advertisement of a "priority" field > > that the server can use to communicate with the client in deciding to > > use the server recommended fetch order or not. > > > > in [3] Christian also implemented the option "promisor.storeFields" which > > allowed the value of the configuration to be saved in the client's > > configuration file for use at a later time. > > As above, this option will also prove important when the server advertises > > the "priority" field as it will allow the client decided to store it in its > > Maybe: s/decided // Thanks > > > config settings for that promisor remote, for later use when fetching > > the remaining blobs from the promisor remotes. > > Yes. > > [...] > > > High Level Approach to Project Execution: > > ========================================= > > > > 1. Introduce the `remote..priority` config option: > > ====================================================== > > As said above, when fetching missing objects, the order in which the remotes > > are queried depends on the order in which they appear in the config file. > > Not sure this is worth repeating three times. Okay > > > To make this flexible, I will introduce the `remote..priority` config option, > > which will allow the client to set its preferred fetch order to each promisor remote > > configuration, and then make it fetch based on this "priority" order. > > The value of this option could be an integer between 1 and 65535, where the smallest > > Why 65535? I considered if the value might be stored in a small unsigned 16 bit integer type and also it will have enough room for many priority levels. But we must not use the exact range (0 - 65535). > > > integer indicates highest priority. > > > > This will allow a promisor remote be configured as follows > > > > [remote "prom1"] > > url = https://prom1.com > > priority = 10 > > > > Therefore when the client is configured with more than one promisor remote > > and the prority is set for each promisor remote as follows, > > s/prority/priority/ Thanks > > > [remote "prom1"] > > url = https://prom1.com > > priority = 20 > > [remote "prom2"] > > url = https://prom2.com > > priority = 10, > > [...] > > > 2. Community Bonding (May 1 - 14, 2026): > > ---------------------------------------- > > - Discuss design details with community and mentors > > - Understand safety, security constraints and design considerations > > when implementing fetch ordering. > > - Read indepth the Documentations for promisor-remote, gitprotocol-v2, > > s/indepth/in depth/ Thank you. I will make the changes and send a v3. Thanks Abraham. ``` ## Abraham Samuel Adekunle, 2026-03-24 22:47 Subject: [GSoC] [Proposal v3]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/acMT0zqd6SiEz5h9%40Adekunles-MacBook-Air.local In-Reply-To: ``` Hello, This is the third iteration of my proposal for the project "Implement promisor remote fetch ordering" for the 2026 GSoC programme. Personal Bio: ============= Full Name: Abraham Samuel Adekunle Email: abrahamadekunle50@gmail.com GitHub: https://github.com/devdekunle Pronouns: he/him About Me: ========= My name is Abraham Samuel Adekunle. I love to code, read and I am a hard worker. In my free time I love to play games and listen to soothing music and well, also shift into diffuse thinking to gain a new perspective of whatever challenge I am trying to solve. I am very curious so I really love to learn as it's a never ending journey, and I believe in the power of "yet". I can understand anything, it is only a matter of time and effort. I love to figure out things and be part of a community where we can share experiences and support each other in growth. Past Experience with Git: ========================= I first learnt about Git during my ALX Software Engineering days in 2022, it proved challenging at first understanding what was going on and a git merge conflict was always a scary experience. Now I feel elated actually contributing to this renowned project. Contributions to the Git Community: ==================================== My first contribution to the Git community was during the contribution phase of the December 2024 Outreachy contribution phase where I first learned to send patches and had my first interactions with the Git code base. I did not make it through then but it was an opportunity to try again. Contributions to other Communities: =================================== I have contributed very sparingly to the Systemd project and also the Linux Kernel. Microproject: ============= Link: https://lore.kernel.org/git/aV_IGCld5T_dBxTs@Adekunles-MacBook-Air.local/ Branch: aa/add-p-previous-decisions Status: Merged to master Commit ID: 8cafc305e22a59efb92472d4132616e24d3184c6 Description: "git add -p" and friends notes what the current status of the hunk being shown is Other Contributions: ==================== 1. Link: https://lore.kernel.org/git/cover.1771066252.git.abrahamadekunle50@gmail.com/ Branch: aa/add-p-no-auto-advance Status: Will merge to master Description: "git add -p" learned a new mode that allows the user to revisit a file that was already dealt with 2. Link: https://lore.kernel.org/git/aWZkEYHhcIhdAjkh@Adekunles-MacBook-Air.local/ Status: Stalled Description: the patch attempts to remove the use of the_repository global variable in some builtins 3. Link: https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@gmail.com/ Branch: sa/notes-edit Status: Merged to master Description: Teach 'git notes add' and 'git notes append' a new '-e' flag, instructing them to open the note in $GIT_EDITOR before saving. 4. Link: https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@gmail.com/ Branch: aa/t7300-modernize Status: Merged to master Description: use test_path_* helper functions for error logging Project Overview and Objective: =============================== I have always wondered what happens in the background when I see these details on my screen in a "git fetch" process. remote: Enumerating objects: 57, done. remote: Counting objects: 100% (57/57), done. remote: Compressing objects: 100% (12/12), done. Receiving objects: 100% (57/57), 48.3 KiB | 512.00 KiB/s, done. Resolving deltas: 100% (21/21), done. remote: Total 57 (delta 21), reused 13 (delta 5), pack-reused 30 From https://example.com/me/repo 1a2b3c4..5d6e7f8 feature/xyz -> origin/feature/xyz And when I saw this project from the list of projects listed, I was endeared to it as it is an opportunity to work in an area of the that Git code base that will satisfy my curiosity while also being mentored by very best and most experienced Engineers there is. When a Git repository is configured with multiple promisor remotes, there is currently no other mechanism to specify or optimize the order in which these remotes should be queried when fetching missing objects. Different remotes may have different performance characteristics, cost, or reliability which makes the fetching order an important consideration. Currently, the promisor remotes are queried in the order in which they appear in the local .git/config, one after the other, until all the objects have been fetched, with the promisor remote configured with the `extension.partialClone` config variable being the last one tried. The project aims to implement a fetch ordering mechanism for multiple promisor remotes that allows a client to be able to specify a fetching order, a server to advertise an order to the client to ensure performance and cost management, the client to decide to use the server advertised order or not, and default to the current order if no order is specified. Review of Previous Work: ======================== The project is part of the Large Object Promisor "LOP" effort documented in Documentation/technical/large-object-promisors.adoc. In a bid to better handle large objects, the promisor-remote capability was added to the Git protocol v2, as documented in the promisor-remote section of Documentation/gitprotocol-v2.adoc. This enables a protocol negotiation so that the server can advertise one or more promisor remotes and the client and server can discuss if the client could directly fetch missing objects from the promisor remote(s) the server is advertising. If an agreement is reached, the client would be able to fetch the missing objects directly from the promisor remote without the server acting as a relay between the client and the promisor remote. The ground work for adding this capability to the v2 protocol was started by Christian Couder in [1], where if the "promisor.advertise" config is set to true, the server can then propagate its promisor remote configurations to the client over the v2 protocol during the negotiation in the form "promisor-remote=name=prom1,url=url_encoded_value1;name=prom2,url=url_encoded_value2" The client can then choose to accept some promisor remotes the server is advertising using the "All", "None", "KnownName" or "KnownUrl" configurations as values for the "promisor.acceptfromServer" config option. In [2], Christian added the option for a server to advertise more fields after the "name" and "url", such as "token" and "partialCloneFilter" for the client to use this additional information in deciding the remotes to use as its promisor remotes by comparing it with its local config information. This was implemented by adding the "promisor.sendFields" and "promisor.checkFields" config values to the server and client respectively. For example, if "promisor.sendFields" is set to "partialCloneFilter", and the server has the remote configured like so: [remote "foo"] url = https://pr.test partialCloneFilter = blob:none token = "fake" then "name=foo,url=https://pr.test,partialCloneFilter=blob:none,token=fake" will be advertised by the server to the client which can then decide, using the "promisor.checkFields" config option, to check if the passed field matches certain conditions before the remote is accepted. in [3] Christian also implemented the option "promisor.storeFields" which allowed the value of the configuration to be saved in the client's configuration file for use at a later time. One fetch order that I will implement is the server recommended fetch order, which the server suggests to the client. To achieve this, I would take advantage of the ground work done by Christian by adding a "priority" field to the promisor-remote capability when the "priority" is added to the "promisor.sendFields" server config option. This indicates that the server is recommending to the client to use its recommended fetch order. If the client chooses to use the server recommended fetch order, it can add "priority" to the "promisor.storeFields" config option which will store this value and query the promisor remotes in the recommended order when fetching the missing objects at a later time. If the client chooses to ignore this recommendation, it can simply choose not to store it and instead use its own preferred order by setting the priority for some or all the remotes to its preferred value and then query the objects in that order. Not using either of these orders will query the promisor remotes in the current default order. High Level Approach to Project Execution: ========================================= 1. Introduce the `remote..priority` config option: ====================================================== To make the fetch order flexible, the first step will be to introduce the `remote..priority` config option, which will allow the client to set its preferred fetch order to each promisor remote configuration, and then make it fetch based on this "priority" order. The value of this option could be a fixed range between 1 - 100 where the smallest integer indicates highest priority. This will allow a promisor remote be configured as follows [remote "prom1"] url = https://prom1.com priority = 10 Therefore when the client is configured with more than one promisor remote and the prority is set for each promisor remote as follows, [remote "prom1"] url = https://prom1.com priority = 20 [remote "prom2"] url = https://prom2.com priority = 10, when fetching for the missing objects, the promisor remote "prom2" will be queried first before "prom1". 2. Server Side Advertisement: ----------------------------- After the `remote..priority` config option has been implemented and the fetch order can be changed, I will then allow the server to advertise its recommended fetch order in the promisor-remote capability. As the server knows about the promisor remotes which hold the missing objects, it could recommend the order in which these remotes could be queried by the client using a "priority=" field of the promisor-remote capability in the Git v2 protocol, where could be a fixed range integer between 1 and 100, and the smallest integer indicates highest priority. This will be an optional feature which will be enabled by the server if it wants to recommend ordered fetching to the client via the "promisor.sendFields=priority" config option. Hence if the server advertises promisor remotes prom1 and prom2, it could be of the form "promisor-remote=name=prom1,url=https://prom1.com,priority=10;name=prom2,url=https://prom2.com,priority=20", if the server is configured as: [remote "prom1"] url = https://prom1.com priority = 10 [remote "prom2"] url = https://prom2.com priority = 20 If the "promisor.sendFields" values does not include the "priority" field in its comma or space separated options, the field will not be advertised in the promisor-remote capability. 3. Client Side Parsing: ----------------------- After the "priority" field has been advertised in the promisor-remote capability, the client can choose to use this server recommended fetch order or ignore it completely. If the client wants to use the server recommended fetch order later when fetching the missing objects from the accepted promisor remotes, the "priority" field will be added to the "promisor.storeFields" config options so that the passed value can be saved to the client config. If the client does not enable this option in the config, the "priority" field will not be saved in the local config and the fetching order will be client specified order if set or the default local config order if not set. The three different fetch order are; 1. the order advertised by the server, where the "priority" field will be added to "promisor.storeFields" and the value will be saved to the local config file for the selected promisor remotes. When fetching the missing objects, this order will be used. 2. the local "priority" config where the client can set the "priority" field using, priority=, of some or all "remote." to indicate its preferred fetch order when fetching the missing objects. This order will be used if the "promisor.storeFields" does not include the "priority" field. 3. the default order, where the field will not be added to the config and hence the current default order will be used. Proposed Project Execution Timeline: ==================================== Estimated Project Size: 350 hours 1. Study code base to understand promisor-remote and fetch mechanism (May 1 - 14, 2026): ------------------------------------------------------------------------------------- - Study the code base to understand how the client and server communicate using the protocol when client contacts the server. - Study how Git currently handles fetching from multiple remotes. - Set up blog for posting once in two weeks 2. Community Bonding (May 1 - 14, 2026): ---------------------------------------- - Discuss design details with community and mentors - Understand safety, security constraints and design considerations when implementing fetch ordering. - Read in depth the Documentations for promisor-remote, gitprotocol-v2, and other necessary documentations. - Post updates on my blog 3. Review Existing Patches and related code (May 15 - May 25, 2026): ------------------------------- - Study code base to understand how a new config option is added. - study code that handles the fetching of missing objects after a partial clone/fetch. - Study Christian's patches in-depth to understand how a new field is added to the promisor remote of server, what conditions are used to ensure the data is of the right format, correctly passed from server to client, and correctly parsed and stored by client. - Study how a client can store the new field it accepts to use from the advertised fields. - Understand the tests to see how these new features are tested - Post updates on my blog 4. Introduce the `remote..priority` config option: (May 25 - June 13, 2026): ------------------------------------------------------- - Discuss with mentors on the suggested approach - Allow the addition of the config option `remote..priority` - Implement fetching based on this option when set by the client and if not set, default to the current order. - Write tests to ensure proper implementation of the new config and fetch order - Submit patches to mailing list and engage in reviews with Community members - Post update on my blog 5. Allow a server to add the "priority" field to the promisor-remote capability (June 14 - June 21, 2026) ------------------------------------------------------------------------------- - Discuss with mentors on the suggested approach - Allow the server to add the field "priority" to the promisor-remote capability when it is enabled in "promisor.sendFields". - Write tests to ensure proper implementation - Update documentation in Documenantation/config/promisor.adoc - Submit patch to mailing list for discussions and address reviews - Post updates on my blog 6. Allow Client to decide to use the field (June 21 - 14, 2026): ----------------------------------------------------------------- - Discuss strategy with mentors - Allow the client to store the "priority" in its .git/config if it accepts the promisor remotes and it is included in "promisor.storeFields" - Write unit tests to ensure proper implementations - Update documentation in Documentation/config/promisor.adoc - Submit patches to mailing list for reviews and address feedbacks - Post updates on my blog 7. Implement fetching order based on setting: (July 15 - August 14, 2026): ------------------------------------------------------------------------ - Discuss with mentors on the approach and considerations for fetch order - Implement fetching based on the client's accepted fetching order - Write unittests to test implementation - Update documentation in Documenantation/config/promisor.adoc - Submit patches for review and address reviews - Post updates on my blog 9. Final Report on Project (August 15 - 24, 2026): -------------------------------------------------- - Document any final report in my blog with details of my experience - Finalize any pending tasks Availability: ============= I will be able to give 30 hours a week to make the project a success Post GSoC ========= Though this is not my first contribution to Git, as I have contributed very lightly to the codebase before, I am committed to continuously contributing to Git and become a part of the next set of contributors to champion the continuous development of Git. Appreciation ============ To Junio C Hamano, Phillip Wood, and everyone who helped with my patches. I really appreciate your guidance, patience and direction while reviewing and my patches. Thanks References =========== 1. https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/ 2. https://lore.kernel.org/git/20250908053056.956907-1-christian.couder@gmail.com/ 3. https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/ ``` ## Samuel Abraham, 2026-03-30 21:50 Subject: Re: [GSoC] [Proposal v3]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CADYq%2BfbsXVtYZcq2wB2FoyUzDdzZKJYEN2EZk1uOvdihMyJzVA%40mail.gmail.com In-Reply-To: ``` On Tue, Mar 24, 2026 at 11:47 PM Abraham Samuel Adekunle wrote: > > Hello, > This is the third iteration of my proposal for the project > "Implement promisor remote fetch ordering" for the 2026 GSoC programme. > Hello. Just bumping this up to know if this version is okay for submission to the GSoC site. Thanks Abraham. ``` ## Christian Couder, 2026-03-31 07:25 Subject: Re: [GSoC] [Proposal v3]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CAP8UFD3xsMc%2BirB0Aiit3rMqHeSqodeKpSRRvjOKFGF-vvmx-Q%40mail.gmail.com In-Reply-To: ``` Hi, On Mon, Mar 30, 2026 at 11:50 PM Samuel Abraham wrote: > > On Tue, Mar 24, 2026 at 11:47 PM Abraham Samuel Adekunle > wrote: > > > > Hello, > > This is the third iteration of my proposal for the project > > "Implement promisor remote fetch ordering" for the 2026 GSoC programme. > > > Hello. > > Just bumping this up to know if this version is okay for submission to > the GSoC site. > Thanks Sorry but we won't likely have time to review your proposal and other proposals before the end of the application period today at 18:00 UTC. So everyone should submit their proposal on the GSoC site as-is now if they haven't already done so. Best, Christian. ``` ## Samuel Abraham, 2026-03-31 10:10 Subject: Re: [GSoC] [Proposal v3]: Implement promisor remote fetch ordering Message-ID: URL: https://gitlist.dev/e/CADYq%2BfZGtWz62U-ur50_Ee%2BKvA0BPvXPPQ1dNwsx0%2BqxPdydHA%40mail.gmail.com In-Reply-To: ``` On Tue, Mar 31, 2026 at 8:26 AM Christian Couder wrote: > > Hi, > > On Mon, Mar 30, 2026 at 11:50 PM Samuel Abraham > wrote: > > > > On Tue, Mar 24, 2026 at 11:47 PM Abraham Samuel Adekunle > > wrote: > > > > > > Hello, > > > This is the third iteration of my proposal for the project > > > "Implement promisor remote fetch ordering" for the 2026 GSoC programme. > > > > > Hello. > > > > Just bumping this up to know if this version is okay for submission to > > the GSoC site. > > Thanks > > Sorry but we won't likely have time to review your proposal and other > proposals before the end of the application period today at 18:00 UTC. > > So everyone should submit their proposal on the GSoC site as-is now if > they haven't already done so. > Thank you Christian I will do that Abraham ```