# [GSoC][PROPOSAL] Improve the new git repo command 3 messages from 2026-03-01 to 2026-03-17. Participants: JAYATHEERTH K, Karthik Nayak, K Jayatheerth. Thread: https://gitlist.dev/t/65105 ## JAYATHEERTH K, 2026-03-01 03:10 Subject: [GSoC][PROPOSAL] Improve the new git repo command Message-ID: URL: https://gitlist.dev/e/CA%2BrGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg%40mail.gmail.com ``` Hey everyone, This is my proposal for the project `Improve the new git repo command`. --- = GSoC 2026 PROPOSAL: IMPROVE THE NEW GIT REPO COMMAND Jayatheerth Kulkarni v1.0, March 1, 2026 == 1. ABOUT ME I am a junior at Geethanjali College of Engineering and Technology pursuing a bachelor's degree, with a strong interest in open-source projects and systems programming. My interest in the Git project stems from a desire to understand the internals of version control and contribute to a tool that is fundamental to the global software development ecosystem. === 1.1 Contact * Email: jayatheerthkulkarni2005@gmail.com * Website: https://jayatheerth.com/ * GitHub: https://github.com/jayatheerthkulkarni * LinkedIn: https://www.linkedin.com/in/jayatheerth/ === 1.2 Logistics * Timezone: Indian Standard Time (IST) / UTC+05:30 * Tech Stack: C, Shell Scripting, Rust and Go == 2. CONTRIBUTION HISTORY I have formally completed all the prerequisites to apply for the GSoC "Improve the new git repo command" project. I have listed all of my work I have done in the past few months. === 2.1 Featured Contributions For many months, I have been actively engaging with the Git community through mailing list discussions and patch submissions. Notably, my work on fixing stash messaging behavior in submodule environments was featured in Git Rev-News edition 124. * [PATCH v3] stash: fix incorrect branch name in stash message* Status: Merged into `master` & featured in Git Rev-News. Link: https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/T/#u === 2.2 Core Path and Submodule Patches * [PATCH v8] submodule: prevent overwriting .gitmodules entry on path reuse* Status: Merged into `master`. Link: https://lore.kernel.org/git/20250608032705.11990-1-jayatheerthkulkarni2005@gmail.com/T/#u * [PATCH v2] dir: Fix and test wildcard pathspec handling* Status: Merged into `master`. Link: https://lore.kernel.org/git/20250422160547.577524-1-jayatheerthkulkarni2005@gmail.com/ === 2.3 Refactoring and Micro-Projects I am deeply familiar with Git's test suite and standard C conventions, having submitted several refactoring and cleanup patches, including two specific to the `builtin/repo.c` file: * [PATCH GSoC] repo: Remove unnecessary variable shadow* Status: Merged into `next` Link: https://lore.kernel.org/git/aZxyju3B4NHp4c_t@denethor/T/#t * [GSoC] t7101: modernize test path checks* Status: Merged into `master` (Official micro-project). Link: https://lore.kernel.org/git/CALE2CrS0Q2NS1DbFv4pyRQsuypu=KH6Kurs=m4yWrFbR9QosoA@mail.gmail.com/T/#t * [PATCH v2] pull: move options[] array into function scope* Status: Merged to `master`. Link: https://lore.kernel.org/git/20251212074433.38027-1-jayatheerthkulkarni2005@gmail.com/T/#u === 2.4 Documentation * [PATCH v3] Update MyFirstContribution.adoc to follow modern practices* Status: Merged to `master`. Link: https://lore.kernel.org/git/CA+rGoLfFVcUFctoEx6wshovGnRW8pTW--ZB42ntd01VHMJm_Rw@mail.gmail.com/T/#t === 2.5 Experience with C Since Git is mainly written in C, I have no issues navigating the codebase. I hold a Cisco CLP - Advanced C Programming certificate covering Unix and C systems programming, and I have completed two full university semesters of C programming. == 3. PROJECT PROPOSAL === 3.1 Why "Improve the new git repo command"? This project is compelling because I have closely followed its development since its inception in GSoC 2025. Consistently reading the weekly updates (https://lucasoshiro.github.io/gsoc-en/) and participating in the mailing list discussions has given me a deep understanding of the command's architecture. My previous work fixing cross-platform wildcard pathspecs in `dir.c` makes me uniquely suited to tackle the path resolution this project requires, while my C systems experience prepares me for the architectural refactoring of the command. === 3.2 Introduction The new `git repo info` command is positioned to be a cleaner, programmatic replacement for scraping `git rev-parse`. However, its current implementation lacks category-based querying, relies on global state macros, and is missing critical path data. To fully realize Git's libification effort and improve user experience, the internal architecture of `builtin/repo.c` must be modernized. === 3.3 Proposed Solution and Objectives Instead of just scraping basic paths, I propose an architectural update to `repo info`, safely utilizing the new `strbuf_add_path` API submitted by Lucas Oshiro. *Objective 1: Category-Based Query Architecture (The Core API)* + Currently, the `repo_info_fields` array relies on an exact-match binary search (`bsearch`). Users must request specific keys or use `--all`. I will rewrite the lookup logic to support category-prefix matching. * *Implementation:* I will implement an internal mapping structure so that calling `git repo info path` successfully identifies the category root and iterates through all keys starting with `path.*`, returning them dynamically. *Objective 2: Deep Libification (Removing Global State)* + The `builtin/repo.c` file is already highly modernized, but it opts into global state by declaring `USE_THE_REPOSITORY_VARIABLE` at the top of the file. * *Implementation:* I will remove this macro entirely. The primary blocker in this file is `get_layout_bare()`, which currently marks its local `repo` argument as `UNUSED` and falls back to the global `is_bare_repository()` helper. I will refactor this function to drop the `UNUSED` tag and explicitly evaluate the passed `struct repository *repo` pointer. I will thread this context down the call chain without breaking existing external callers. *Objective 3: Core Path Resolution (`git rev-parse` parity)* + With the category API built, I will populate the `path.*` category by implementing the remaining path values currently obtained through `git rev-parse` and `--git-path`. Lucas Oshiro's recent patch series implemented `path.toplevel`; https://lore.kernel.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/T/#t I will build upon this foundation to implement the rest. Because path normalizations across different systems are complex, I will leverage my experience from `dir.c` to safely implement: * `path.git-dir`, `path.common-dir`, `path.worktree`. * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`. *Objective 4: Sparse Topology & Boundary Awareness* + Modern Git workflows rely heavily on partial checkouts and submodules, and `repo info` should report these complex states natively. * *Implementation:* I will implement `layout.is-sparse` to expose if the repository uses a sparse-checkout cone, and `path.superproject-working-tree` to instantly query if the current repository is a submodule. == 4. PROJECT TIMELINE === 4.1 Community Bonding Period (May 1 - May 24) * Attend the Git community GSoC sessions to introduce myself and establish a communication schedule. * Initiate the design discussion on the mailing list regarding the internal data structure for Category-Based Queries. * Map out the exact C call chains affected by `USE_THE_REPOSITORY_VARIABLE` in `builtin/repo.c`. === 4.2 Phase 1: Category Architecture & Core Paths (May 25 - July 5) *Weeks 1 - 3 (May 25 - June 14):* * Implement the category-based lookup mechanism in `builtin/repo.c`. * Update the parsing logic so `git repo info ` successfully returns all nested keys. *Weeks 4 - 6 (June 15 - July 5):* * Utilize Lucas's `strbuf_add_path` API to implement the core path values. * Implement path related keys. (`path.git-dir`, `path.common-dir`, `path.worktree`, `path.objects`, `path.hooks`, `path.index`, and `path.grafts`) * Write rigorous OS-agnostic tests in `t/` to ensure path resolution works correctly across POSIX and Windows environments. === 4.3 Mid-Term Evaluation Phase (July 6 - July 10) * Ensure the category architecture and core paths are merged into `master` or queued in `next`. * Review progress with mentors and adjust the Phase 2 timeline if necessary. * Submit mid-term evaluation. === 4.4 Phase 2: Removing Global State & Sparse Topology (July 11 - August 16) *Weeks 7 - 9 (July 11 - July 26):* * Focus entirely on libification. * Remove the `USE_THE_REPOSITORY_VARIABLE` macro from `builtin/repo.c`. * Refactor `get_layout_bare()` and similar functions to utilize the explicit `repo` parameter. *Weeks 10 - 12 (July 27 - August 16):* * Implement the advanced topology and boundary keys (`layout.is-sparse` and `path.superproject-working-tree`). * Run the full test suite and perform rigorous edge-case testing ensuring libification does not cause regressions. * Buffer period for addressing mailing list feedback regarding the libification and sparse patches. === 4.5 Finalization (August 17 - August 24) * Finalize the official Git documentation (`Documentation/git-repo.txt`) for all new keys and category querying. * Clean up the commit history and ensure all patches are finalized on the mailing list. * Submit the final GSoC project report. === 4.6 Stretch Goals If review cycles move faster than anticipated, I will implement Split-Index Topology (`path.shared-index`) to report the path to the shared index file. I will also investigate natively parsing `git-sizer` metrics into the newly established category API to provide deeper repository health insights. == 5. AVAILABILITY AND BLOGGING This timeline aligns perfectly with my schedule. The project kicks off in May, during which I will be on summer vacation and can dedicate 35-50 hours a week. During June and July, I will transition into my final year of university. My academic schedule during this period is highly flexible. *Blogging:* + I have a domain setup at jayatheerth.com. As patches flow and the project progresses, I will host a dedicated endpoint at `/blogs` to provide comprehensive, weekly coverage of my project. == 6. POST GSOC COMMITMENT I actively follow the mailing list and intend to continue contributing bug fixes and enhancements. I have been a part of the Git community since 2025 and hopefully will continue to be one for a long time. --- End of proposal --- Regards - Jayatheerth ``` ## Karthik Nayak, 2026-03-17 10:44 Subject: Re: [GSoC][PROPOSAL] Improve the new git repo command Message-ID: URL: https://gitlist.dev/e/CAOLa%3DZS6HtJrWd0kfsFASCbP2S9-MQq5Da3feA0WqY8ykZ0WTw%40mail.gmail.com In-Reply-To: ``` JAYATHEERTH K writes: Hello, > Hey everyone, > > This is my proposal for the project > `Improve the new git repo command`. > > --- > = GSoC 2026 PROPOSAL: IMPROVE THE NEW GIT REPO COMMAND > Jayatheerth Kulkarni > v1.0, March 1, 2026 > > == 1. ABOUT ME > > I am a junior at Geethanjali College of Engineering and > Technology pursuing a bachelor's degree, with a strong > interest in open-source projects and systems programming. > My interest in the Git project stems from a desire to > understand the internals of version control and contribute > to a tool that is fundamental to the global software > development ecosystem. > > === 1.1 Contact > * Email: jayatheerthkulkarni2005@gmail.com > * Website: https://jayatheerth.com/ > * GitHub: https://github.com/jayatheerthkulkarni > * LinkedIn: https://www.linkedin.com/in/jayatheerth/ > > === 1.2 Logistics > * Timezone: Indian Standard Time (IST) / UTC+05:30 > * Tech Stack: C, Shell Scripting, Rust and Go > > == 2. CONTRIBUTION HISTORY > > I have formally completed all the prerequisites to apply > for the GSoC "Improve the new git repo command" project. > I have listed all of my work I have done in the past few > months. > > === 2.1 Featured Contributions > > For many months, I have been actively engaging with the > Git community through mailing list discussions and patch > submissions. Notably, my work on fixing stash messaging > behavior in submodule environments was featured in Git > Rev-News edition 124. > > * [PATCH v3] stash: fix incorrect branch name in stash message* > Status: Merged into `master` & featured in Git Rev-News. > Link: https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/T/#u > > === 2.2 Core Path and Submodule Patches > > * [PATCH v8] submodule: prevent overwriting .gitmodules entry on path reuse* > Status: Merged into `master`. > Link: https://lore.kernel.org/git/20250608032705.11990-1-jayatheerthkulkarni2005@gmail.com/T/#u > > * [PATCH v2] dir: Fix and test wildcard pathspec handling* > Status: Merged into `master`. > Link: https://lore.kernel.org/git/20250422160547.577524-1-jayatheerthkulkarni2005@gmail.com/ > > === 2.3 Refactoring and Micro-Projects > > I am deeply familiar with Git's test suite and standard > C conventions, having submitted several refactoring and > cleanup patches, including two specific to the > `builtin/repo.c` file: > > * [PATCH GSoC] repo: Remove unnecessary variable shadow* > Status: Merged into `next` > Link: https://lore.kernel.org/git/aZxyju3B4NHp4c_t@denethor/T/#t > > * [GSoC] t7101: modernize test path checks* > Status: Merged into `master` (Official micro-project). > Link: https://lore.kernel.org/git/CALE2CrS0Q2NS1DbFv4pyRQsuypu=KH6Kurs=m4yWrFbR9QosoA@mail.gmail.com/T/#t > > * [PATCH v2] pull: move options[] array into function scope* > Status: Merged to `master`. > Link: https://lore.kernel.org/git/20251212074433.38027-1-jayatheerthkulkarni2005@gmail.com/T/#u > > === 2.4 Documentation > > * [PATCH v3] Update MyFirstContribution.adoc to follow modern practices* > Status: Merged to `master`. > Link: https://lore.kernel.org/git/CA+rGoLfFVcUFctoEx6wshovGnRW8pTW--ZB42ntd01VHMJm_Rw@mail.gmail.com/T/#t > > === 2.5 Experience with C > > Since Git is mainly written in C, I have no issues > navigating the codebase. I hold a Cisco CLP - Advanced C > Programming certificate covering Unix and C systems > programming, and I have completed two full university > semesters of C programming. > > == 3. PROJECT PROPOSAL > > === 3.1 Why "Improve the new git repo command"? > > This project is compelling because I have closely followed > its development since its inception in GSoC 2025. > Consistently reading the weekly updates > (https://lucasoshiro.github.io/gsoc-en/) and participating > in the mailing list discussions has given me a deep > understanding of the command's architecture. > My previous work fixing cross-platform wildcard pathspecs > in `dir.c` makes me uniquely suited to tackle the path > resolution this project requires, while my C systems > experience prepares me for the architectural refactoring > of the command. > > === 3.2 Introduction > > The new `git repo info` command is positioned to be a > cleaner, programmatic replacement for scraping > `git rev-parse`. However, its current implementation lacks > category-based querying, relies on global state macros, > and is missing critical path data. > To fully realize Git's libification effort and improve > user experience, the internal architecture of > `builtin/repo.c` must be modernized. > > === 3.3 Proposed Solution and Objectives > > Instead of just scraping basic paths, I propose an > architectural update to `repo info`, safely utilizing the > new `strbuf_add_path` API submitted by Lucas Oshiro. > > *Objective 1: Category-Based Query Architecture (The Core API)* + > Currently, the `repo_info_fields` array relies on an > exact-match binary search (`bsearch`). Users must request > specific keys or use `--all`. > I will rewrite the lookup logic to support > category-prefix matching. > * *Implementation:* I will implement an internal mapping > structure so that calling `git repo info path` > successfully identifies the category root and iterates > through all keys starting with `path.*`, returning them > dynamically. > This would definitely be nice to have. Have you also thought about glob pattern matching too? That way a user could do $ git repo info "path*" And have it list all keys which start with path. Similar to how you plan to do category matching, but this can also do $ git repo info "*object*" So any keys with object in it would match too. Either ways I'm just thinking out loud and not saying this is what you _should_ do. > *Objective 2: Deep Libification (Removing Global State)* + > The `builtin/repo.c` file is already highly modernized, > but it opts into global state by declaring > `USE_THE_REPOSITORY_VARIABLE` at the top of the file. > * *Implementation:* I will remove this macro entirely. > The primary blocker in this file is `get_layout_bare()`, > which currently marks its local `repo` argument as > `UNUSED` and falls back to the global > `is_bare_repository()` helper. > I will refactor this function to drop the `UNUSED` tag > and explicitly evaluate the passed > `struct repository *repo` pointer. > I will thread this context down the call chain without > breaking existing external callers. > It would be nice to collate some of the efforts already made in this direction, I know its not as simple [1] as passing in the repo since `is_bare_repository()` has a lot of callees. > *Objective 3: Core Path Resolution (`git rev-parse` parity)* + > With the category API built, I will populate the `path.*` > category by implementing the remaining path values currently > obtained through `git rev-parse` and `--git-path`. > Lucas Oshiro's recent patch series implemented `path.toplevel`; > https://lore.kernel.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/T/#t > I will build upon this foundation to implement the rest. > Because path normalizations across different systems are > complex, I will leverage my experience from `dir.c` to safely implement: > * `path.git-dir`, `path.common-dir`, `path.worktree`. > * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`. > This is the crux, but you should also probably involve some of the newer discussions around this. I added some pointers to Mansi's proposal, and perhaps that's something you should look into too. [2] > *Objective 4: Sparse Topology & Boundary Awareness* + > Modern Git workflows rely heavily on partial checkouts > and submodules, and `repo info` should report these > complex states natively. > * *Implementation:* I will implement `layout.is-sparse` > to expose if the repository uses a sparse-checkout > cone, and `path.superproject-working-tree` to instantly > query if the current repository is a submodule. > Those may be good additions. > == 4. PROJECT TIMELINE > > === 4.1 Community Bonding Period (May 1 - May 24) > > * Attend the Git community GSoC sessions to introduce > myself and establish a communication schedule. > * Initiate the design discussion on the mailing list > regarding the internal data structure for > Category-Based Queries. > * Map out the exact C call chains affected by > `USE_THE_REPOSITORY_VARIABLE` in `builtin/repo.c`. > > === 4.2 Phase 1: Category Architecture & Core Paths > (May 25 - July 5) > > *Weeks 1 - 3 (May 25 - June 14):* > * Implement the category-based lookup mechanism in > `builtin/repo.c`. > * Update the parsing logic so `git repo info ` > successfully returns all nested keys. > > *Weeks 4 - 6 (June 15 - July 5):* > * Utilize Lucas's `strbuf_add_path` API to implement the > core path values. > * Implement path related keys. > (`path.git-dir`, `path.common-dir`, `path.worktree`, > `path.objects`, `path.hooks`, `path.index`, and `path.grafts`) > * Write rigorous OS-agnostic tests in `t/` to ensure path > resolution works correctly across POSIX and Windows > environments. I think this will take way more time than the two weeks allocated here, mostly because of the design decisions we need finalize on. > > === 4.3 Mid-Term Evaluation Phase (July 6 - July 10) > > * Ensure the category architecture and core paths are > merged into `master` or queued in `next`. > * Review progress with mentors and adjust the Phase 2 > timeline if necessary. > * Submit mid-term evaluation. > > === 4.4 Phase 2: Removing Global State & Sparse Topology > (July 11 - August 16) > > *Weeks 7 - 9 (July 11 - July 26):* > * Focus entirely on libification. > * Remove the `USE_THE_REPOSITORY_VARIABLE` macro from > `builtin/repo.c`. > * Refactor `get_layout_bare()` and similar functions to > utilize the explicit `repo` parameter. > > *Weeks 10 - 12 (July 27 - August 16):* > * Implement the advanced topology and boundary keys > (`layout.is-sparse` and `path.superproject-working-tree`). > * Run the full test suite and perform rigorous edge-case > testing ensuring libification does not cause > regressions. > * Buffer period for addressing mailing list feedback > regarding the libification and sparse patches. > Overall I think this is trying to do many things in a short time frame. I would also consider the time it takes for reviews and iterations to land. > === 4.5 Finalization (August 17 - August 24) > > * Finalize the official Git documentation > (`Documentation/git-repo.txt`) for all new keys and > category querying. > * Clean up the commit history and ensure all patches are > finalized on the mailing list. > * Submit the final GSoC project report. > > === 4.6 Stretch Goals > > If review cycles move faster than anticipated, I will > implement Split-Index Topology (`path.shared-index`) > to report the path to the shared index file. I will > also investigate natively parsing `git-sizer` metrics > into the newly established category API to provide > deeper repository health insights. > > == 5. AVAILABILITY AND BLOGGING > > This timeline aligns perfectly with my schedule. > The project kicks off in May, during which I will be on > summer vacation and can dedicate 35-50 hours a week. > During June and July, I will transition into my final > year of university. > My academic schedule during this period is highly > flexible. > > *Blogging:* + > I have a domain setup at jayatheerth.com. > As patches flow and the project progresses, I will host a > dedicated endpoint at `/blogs` to provide comprehensive, > weekly coverage of my project. > > == 6. POST GSOC COMMITMENT > > I actively follow the mailing list and intend to continue > contributing bug fixes and enhancements. > I have been a part of the Git community since 2025 and > hopefully will continue to be one for a long time. > > --- End of proposal --- > > Regards > - Jayatheerth Regards, Karthik [1]: https://lore.kernel.org/git/xmqqbji0b5ak.fsf@gitster.g/#t [2]: CAOLa=ZTtNSZ904v0-SN16jAis7gK4=MVj1g_5CGdbmaBopeZkg@mail.gmail.com ``` ## K Jayatheerth, 2026-03-17 14:47 Subject: Re: [GSoC][PROPOSAL] Improve the new git repo command Message-ID: URL: https://gitlist.dev/e/CA%2BrGoLe70x2Ns5e8qHm3n-yvNxQbAc1b%3DMqm31GDsMCOfJjNFw%40mail.gmail.com In-Reply-To: ``` Hey Karthik, Thank you for taking time to go through the proposal. > > * *Implementation:* I will implement an internal mapping > > structure so that calling `git repo info path` > > successfully identifies the category root and iterates > > through all keys starting with `path.*`, returning them > > dynamically. > > > > This would definitely be nice to have. Have you also thought about glob > pattern matching too? That way a user could do > > $ git repo info "path*" > > And have it list all keys which start with path. Similar to how you plan > to do category matching, but this can also do > > $ git repo info "*object*" > > So any keys with object in it would match too. Either ways I'm just > thinking out loud and not saying this is what you _should_ do. > I hadn't thought about globbing till now but I have now given it a thought, I personally believe we don't need globs (at least not now) There are hardly 4 elements in the array `repo_info_field` as of now even if we add all the paths I think it will not go beyond 20 elements. And I think globbing is a problem we would have to debate after we get to >= 30 elements, globbing has its advantages, it gets insanely flexible but I don't believe it is a current problem. I could however add an RFC in the community bonding period. > > and explicitly evaluate the passed > > `struct repository *repo` pointer. > > I will thread this context down the call chain without > > breaking existing external callers. > > > > It would be nice to collate some of the efforts already made in this > direction, I know its not as simple [1] as passing in the repo since > `is_bare_repository()` has a lot of callees. > After posting this proposal I was tweaking around and found out repo->worktree It holding a `NULL` value is directly supposed to indicate it is `bare` if I am correct? I maybe wrong here But writing up a quick change where static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf) { strbuf_addstr(buf, is_bare_repository() ? "true" : "false"); return 0; } becomes static int get_layout_bare(struct repository *repo, struct strbuf *buf) { strbuf_addstr(buf, (repo->worktree == NULL) ? "true" : "false"); return 0; } and removing the macro #define USE_THE_REPOSITORY_VARIABLE would work is what I have dug so far I would of course not send a patch until GSoC starts But I wanted to know if I am thinking in the right direction here? > > * `path.git-dir`, `path.common-dir`, `path.worktree`. > > * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`. > > > > This is the crux, but you should also probably involve some of the newer > discussions around this. I added some pointers to Mansi's proposal, and > perhaps that's something you should look into too. [2] > That's a great point I will update this. > > *Objective 4: Sparse Topology & Boundary Awareness* + > > Modern Git workflows rely heavily on partial checkouts > > and submodules, and `repo info` should report these > > complex states natively. > > * *Implementation:* I will implement `layout.is-sparse` > > to expose if the repository uses a sparse-checkout > > cone, and `path.superproject-working-tree` to instantly > > query if the current repository is a submodule. > > > > Those may be good additions. > > > == 4. PROJECT TIMELINE > > > > === 4.1 Community Bonding Period (May 1 - May 24) > > > > * Attend the Git community GSoC sessions to introduce > > myself and establish a communication schedule. > > resolution works correctly across POSIX and Windows > > environments. > > I think this will take way more time than the two weeks allocated here, > mostly because of the design decisions we need finalize on. > I agree, I have actually changed a lot of my existing proposal I had a very hard time picking which project to leave out of scope since I like all the projects equally But I did double the allocated time in my existing proposal, I gave 4 weeks for paths and libification (Given that my above trail of thinking is correct it is just a small change i.e repo->worktree) I also gave 4 weeks for querying the prefixes Gave a 3 weeks of buffer for path and libification and 2 weeks of buffer for query. > > *Weeks 10 - 12 (July 27 - August 16):* > > * Implement the advanced topology and boundary keys > > (`layout.is-sparse` and `path.superproject-working-tree`). > > * Run the full test suite and perform rigorous edge-case > > testing ensuring libification does not cause > > regressions. > > * Buffer period for addressing mailing list feedback > > regarding the libification and sparse patches. > > > > Overall I think this is trying to do many things in a short time frame. > I would also consider the time it takes for reviews and iterations to > land. > I just wanted to say that the proposal I posted is in a new thread I understand making it inline is nice But since a lot has changed I thought of adding it in a new thread to justify it [1] Regards, - Jayatheerth 1 - https://lore.kernel.org/git/CA+rGoLd4ho5AmB3gWYP=yUUKJO=YqthxKX8R_rvN7V7exArn6Q@mail.gmail.com/T/#u ```