Vivan Garg wrote: Hi Vivan, Sorry for the delay in re-reviewing! You've largely addressed my original comments, so I only had a few follow-up questions/notes to add. > +# In GSoC > + > +## Plan > + > +Plan > + > +The proposed idea of increasing "sparse-index" integrations may appear straightforward > +initially. However, after reviewing previous implementations, I have found that this > +idea can present unforeseen difficulties for some functions. For example, to enable > +"sparse-index," we must ensure that "sparse-checkout" is compatible with the target > +Git command. Achieving this compatibility requires modifying the original command > +logic, which can lead to other unanticipated issues. Therefore, I have incorporated > +additional steps in the plan, to the steps proposed by the community and mentors, > +outlined below to proactively address potential complications. > + > +1. Conduct an investigation to determine if a Git command functions properly with > + sparse-checkout. This step is estimated to take approximately 7-14 days. > + > +2. Modify the logic of the Git command, if necessary, to ensure it functions > + properly with sparse-checkout. Develop corresponding tests to validate the > + modifications. This step is estimated to take approximately 7-14 days. I'm guessing these two steps will be much shorter if the command is already compatible with sparse-checkout (<7 days for step 1, and you could skip step 2 entirely)? > + > +3. Add tests to t1092-sparse-checkout-compatibility.sh for the built-in, focusing > + on what happens for paths outside of the sparse-checkout cone. > + > +4. Disable the command_requires_full_index setting in the built-in and ensure > + the tests pass. > + > +5. If the tests do not pass, then alter the logic to work with the sparse index. > + > +6. Add tests to check that a sparse index stays sparse. > + > +7. Add performance tests to demonstrate speedup. > + > +8. If any changes are made that affect the behavior of the Git command, update > + the documentation accordingly. Note that such changes should be rare. > + > +Points 3-8 combined should take approximately 15-30 days. Does this also account for the time _after_ submission to the mailing list? Responding to review comments, iterating on changes, etc? > + > +To summarize, each integration will follow a similar schedule to the one outlined > +above. Therefore, without extending the timeline, we can expect to complete 2-3 i > +ntegrations during the GSoC program period. > + > +Timeline > + > +Determining the exact time arrangement for each integration is difficult, as there > +may be unforeseen challenges that arise during the process. However, based on my > +estimation, I anticipate that each integration will take approximately 1.5 - 2 months > +to complete, starting from May 29th. Please refer to the detailed breakdown of each > +step in the plan section for a more accurate estimate. > +The proposed integration schedule is as follows: > + > +• git describe > +• git write-tree > +• git diff-files At this point, initial integrations for both 'git describe' [1] and 'git diff-files' [2] have been submitted to the mailing list. To make your plan more flexible/resilient to concurrent contributions, I think it'd be reasonable to give a list of 5-6 commands you'll choose from to complete your 2-3 planned integrations. [1] https://lore.kernel.org/git/pull.1480.git.git.1679926829475.gitgitgadget@xxxxxxxxx/ [2] https://lore.kernel.org/git/20230322161820.3609-1-cheskaqiqi@xxxxxxxxx/ > + > +This schedule is based on the order of difficulty outlined in GSoC 2023 Ideas. > + > +It's worth noting that each integration may require different amounts of time > +and attention, and modifications to the schedule may be necessary as I delve > +deeper into each command. Nevertheless, I am committed to delivering quality > +results within the given timeframe. > + > +In summary, I anticipate that each integration will take an average of 1.5 months, > +but I remain flexible and open to adjusting the schedule as needed to ensure the > +success of the project. > + > +Availability > + > +I commit to responding to all communication daily and being available throughout > +the duration of the program. While I will be taking some summer courses at my > +university, I will not be enrolled in a typical full course load. As part of GSOC, > +I plan to commit to a medium-sized project of 175 hours. I have experience managing > +my time effectively while taking courses and working full-time internships in the > +past. > + > +The program is officially 16 weeks long. To ensure timely completion of the project, > +I plan to spend 8 hours per week until August 15th, which is when my semester ends. > +From August 16th until September 1st, I plan to dedicate 8 hours per day to the project. > +There are only three weeks during which I would prefer to focus on other things: > +June 23rd-30th (midterm week) and August 1st-15th (finals season). However, as I will be > +committing 8 hours per day following Aug 15th, it should be ample enough to make up for it. Thanks for adding these availability details! > + > +I am confident that I will have ample time to complete the project within the allocated > +time frame. Additionally, I am hoping to continue working on the project even after > +GSOC ends, as there are several functions that need to be implemented. > +
