{"thread":{"id":"61134","subject":"[GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","startedAt":"2024-03-16T18:58:02Z","lastAt":"2024-03-27T00:23:27Z","messageCount":9,"participants":["Aryan Gupta","Christian Couder","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"490794","messageId":"CAMbn=B4HDXOAThvAmmyA5GEzG1nnvbGvc4yjpg7FHSHQQ-WQfw@mail.gmail.com","threadId":"61134","inReplyTo":null,"subject":"[GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Aryan Gupta","fromEmail":"garyan447@gmail.com","sentAt":"2024-03-16T18:57:49Z","receivedAt":"2024-03-16T18:58:02Z","isPatch":false,"sender":{"key":"garyan447@gmail.com","avatar":"https://avatars.githubusercontent.com/u/87857234?v=4"},"body":"Hello everyone.\n\nI hope you are doing well. I am writing this email to get a review for\nmy GSoC proposal.\n\nThanks in advance.\n\nRegards\nAryan\n\nHere it goes:\n\n-- Refactor git-bisect(1) to make its state self-contained --\n=============================================================\n\n-- Personal Info --\n====================\n\nFull name :     Aryan Gupta\nE-mail    :     garyan447@gmail.com\nTel       :     (+91) 7018273899\nEducation :     Graphic Era University, Dehradun, India\nYear      :     Final Year\nMajor     :     Computer Science and Engineering\nGitHub    :     [1]\n\n-- About Me --\n====================\n\nI have been enthusiastic about open source from the very beginning of\nmy journey as a software developer. I’ve contributed to other\nopen-source projects, though still a beginner, I’m generally familiar\nwith the process of contribution. The related experiences are all in\nthe contribution graph on my GitHub profile page [1]. In the ZAP\nProject[2] community, I’ve made over 50 PRs [3]. I also participated\nin the Google Summer of Code 2023 with the OWASP Foundation and\nsuccessfully completed it as well [4]. I have contributed to some\nother small projects as well on GitHub.\n\nI came to participate in the Git community this year (around\nFebruary). I got myself rather comfortable with the contribution\nprocess by writing, replying, and auditing different sorts of patches\nin the community.\n\nWith the patches done so far, I’m getting more familiar with the Git\ninternals, project structures, commonly used APIs, test suites,\nrequired tech stacks, and coding guidelines. For understanding better\nabout Git, I read and reread the documentation a few times, including\n‘MyFirstContribution.txt’, ‘MyFirstObjectWalk.txt’, and ‘Hacking Git’.\nThe book Pro Git also helped me to understand the Git internals\nbetter.\n\nEffective communication with mentors is a very important part of\nGoogle Summer of Code Program. I know when to ask the right questions\nand I do every possible thing I can do before asking any question.\nThis trait of mine always proved to be very useful and I believe it\nwill be really beneficial for me for the completion of this GSoC\nproject as well.\n\n\n-- Before GSoC --\n====================\n\n-- Synopsis --\n-----------------------\n\nI’m picking the project idea “Refactor git-bisect(1) to make its state\nself-contained” from the SoC 2024 Ideas page [5]. This idea aims to\nmake git-bisect(1) self-contained. Its difficulty should be medium,\nand the expected project size takes somewhere between 175 hours to 350\nhours.\n\nThe git-bisect(1) command is used to find a commit in a range of\ncommits that introduced a specific bug. Starting a bisection run\ncreates a set of state files into the Git repository which record\nvarious different parameters like “.git/BISECT_START”. These files\nlook almost like refs due to their names being all-uppercase. This has\nled to confusion with the new “reftable” backend because it wasn’t\nquite clear whether those files are in fact refs or not.\n\nAs it turns out they are not refs and should never be treated like\none. Overall, it has been concluded that the way those files are\ncurrently stored is not ideal. Instead of having a proliferation of\nfiles in the Git directory, it was discussed whether the bisect state\nshould be moved into its own “bisect-state” subdirectory. This would\nmake it more self-contained and thereby avoid future confusion. It is\nalso aligned with the sequencer state used by rebases, which is neatly\ncontained in the “rebase-apply” and “rebase-merge” directories.\n\nThe goal of this project would be to realize this change. While\nrearchitecting the layout should be comparatively easy to do, the\nharder part will be to hash out how to handle backwards compatibility.\n\n-- Benefits to Community --\n--------------------------------\n\nBy joining the community and working on this idea, I can collaborate\nwith my mentors and fellow community members to enhance the user\nexperience for those who use git-bisect(1). Additionally, creating a\nclear distinction between the refs and the git-bisect state files\nthrough this project would be highly beneficial for the community.\n\n-- Why? --\n-----------------\n\nFor me, the biggest question is always why I am doing something. So to\nanswer why I want to contribute to Git in this Google Summer of Code\nis the learning I will get while communicating with the mentors and\nthe git community. I want to learn as much as I could in this phrase.\nAlso, I want a kick start to begin my journey of contributing to git\nfor a long term. Why I chose git was mainly because I wanted to\nexplore something which is being used by almost every software\ndeveloper.\n\n-- Microproject --\n------------------------------\n\n- Modernize a test script [6]\n  - Status: merged into master\n  - Description: Modernize the formatting of the test script to align\nwith current standards and improve its overall readability.\n  - Remarks: This was my first patch in git which helped me to\nunderstand a lot about how the process of submitting a patch and\nreview works.\n\n-- Other Patches --\n----------------------------\n\nOther than the required microproject, I’ve submitted a few other\npatches when I stumbled upon potential modifications, these patches\nare:\n\n- Zero Count Optimization [7]\n  - Status: Under Review\n  - Description: Optimize for efficiency using trailing zeros for set\nbit iteration\n  - Remarks: This was a great learning task. I learned how tiny things\nmatter and small optimizations might make a big impact on performance.\n\n\n-- In GSoC --\n====================\n\n-- Plan --\n----------------\n\nWhat is Git Bisect?\n\nGit Bisect is a git command which helps to find which commit\nintroduced the bug into the codebase at a faster rate by leveraging\nthe power of binary search.\n\n\nThe project idea is relatively easy to understand by the description\nitself. Git bisect stores some state files such as BISECT_START,\nBISECT_FIRST_PARENT etc which looks very similar to the naming\nconvention used for creating the refs file. Due to this similar naming\nconvention it sometimes causes unexpected results when these state\nfiles are confused as the ref files.\n\nIn order to fix this problem we can create a new \".git/bisect-state\"\ndirectory and store all the state files which belong to the\ngit-bisect(1) command in that directory as proposed by Patrick and\nstore all the files as follows.\n\n\n- BISECT_TERMS -> bisect-state/terms\n- BISECT_LOG -> bisect-state/log\n- BISECT_START -> bisect-state/start\n- BISECT_RUN -> bisect-state/run\n- BISECT_FIRST_PARENT -> bisect-state/first-parent\n- BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok\n\nWhile the change looks very simple, it actually is. We will just\nupdate all the paths from where these files are being accessed. When I\nwent through the code of bisect.c file I found that the path is pretty\neasy to configure we just need to modify it at a few places. The main\nproblem is to efficiently handle the backward compatibility and\nimplement proper test cases to not let the existing things break. I\nhave already gone through the bisect.c file a couple of times just\nreading and trying to understand all the functions and was able to\nunderstand a lot of things about how it works.\n\n-- Challenges with Backward Compatibility --\n--------------------------------------------\n\nI plan to implement a migration mechanism that will detect whether the\nlegacy stat file like BISECT_* are present or not during the\ninitialization of git bisect. This migration phase will automatically\nmove these files to the new “.git/bisect-state” directory, ensuring a\nseamless transition for users while maintaining the compatibility with\nexisting scripts and tools. The biggest challenge is not to let the\nexisting functionality break.\n\n\n-- Strategies for Handling Backward Compatibility --\n---------------------------------------------------------\n\n1. Before implementing any changes, a good understanding of how\ngit-bisect works and how it is structured is very important. So, I\nwill thoroughly analyze the existing usage patterns of git-bisect and\nlist down all the potential areas of impact.\n\n2. To validate the codebase changes and ensure the stability and the\nbackward compatibility of git-bisect command. I will write unit tests\nfor all the required changes.\n\n3. I will also try to create some real scenarios where I will be\nmanually testing the desired behavior.\n\n4. We might also need some regression tests to test some of the\nfunctionality which can't be tested using unit tests.\n\nHere is a list of a few tests which I am able to think of as of now:\n\n1. Verify correct relocation of state files during initialization.\n2. Test compatibility with existing bisect scripts and tools.\n3. Validate handling of edge cases, such as empty or corrupted state\nfiles, to prevent unexpected behavior\n\nI am pretty sure I am still missing some of the problems which I may\nface in the future but I will figure them out too when they arrive.\n\n-- Timeline --\n------------------\n\nI will be starting the project as soon as I receive the confirmation\nof my proposal getting selected for GSoC.\n\nHere is a list of phases during the GSoC period for this project.\nWhile these are just the approximations, the actual timeline may vary\nbecause of the review iterations or unpredictable scenarios.\n\n1. Understanding the existing implementation of Bisect command\n    - This includes understanding how to test the changes locally\nwhich are made in the bisect command efficiently\n    - Get more familiar with the style of writing the code\n\n2. Start working on the task to add the directory\n    - Updating all the references wherever these bisect files are used\n    - Writing/Updating tests to test all the changes made\n\n3. Start with supporting backward compatibility\n    - For this phase what I am thinking is of adding a stage just\nafter the initialization of git bisect command which will detect if\nthere exist some files by the name BISECT_* and migrate all those\nfiles into the “.git/bisect” directory.\n\n4. Adding Tests\n    - Through testing for backward compatibility is very very\nimportant so that the changes don’t break the existing changes.\n\n5. Documenting the changes\n    - This might also go side by side if mentors need some weekly\ndocumentation of the tasks done.\n\n\n-- Availability --\n----------------------\n\nI will be able to contribute 2-3 hours on weekdays and minimum 6 hours\non weekends. Which gives me around 22-27 hours per week to work on the\nproject. I will work till a minimum span of 14 weeks (can be extended)\nduring the GSoC. I will try my best to keep this time commitment and\nbe always available through the community’s mailing list. Also, I have\nexams in the first week of June so I will have limited availability\nduring that period. The project might take somewhere around 175-350\nhours.\n\n-- After GSoC --\n---------------------\n\nAfter GSoC I intend to be a part of the community and keep\ncontributing to the git’s codebase. I eagerly want to learn a lot from\nthe git community and enhance my skills. I also see myself making\nimportant contributions to git in the future.\n\nWhen I first joined the community 2 months ago, the ancient way of\ncollaborating through a mailing list by sending diff patches was\nreally puzzling (GitHub was the only means that I knew about for\nopen-source collaboration). After sending a patch I got a little\ncomfortable with it and started loving it.\n\n-- Closing remarks --\n----------------------------\n\nI am really enthusiastic to contribute to git. I really want to learn\na lot from my mentors and the whole git community. Everyone\ncontributes using git, why not contribute to git :).\n\nIn the end I really want to thank the whole community, especially\nChristian and Junio, for their valuable time in reviewing my patches\nand guiding me with the problems I faced.\n\n-- References --\n---------------------\n\n[1]  Github Link - https://github.com/aryangupta701\n[2]  ZAP Project - https://github.com/zaproxy\n[3]  Pull Requests -\nhttps://github.com/search?q=org%3Azaproxy+type%3Apr+sort%3Aupdated-asc++author%3Aaryangupta701&type=pullrequests\n[4]  GSoC 2023 Project -\nhttps://www.zaproxy.org/blog/2023-09-11-browser-recorder/\n[5]  SoC Ideas - https://git.github.io/SoC-2024-Ideas/\n[6]  Migrate Test Script -\nhttps://lore.kernel.org/git/pull.1675.v2.git.1709243831190.gitgitgadget@gmail.com/T/#t\n[7]  Zero Count Optimization-\nhttps://lore.kernel.org/git/20240310162614.62691-2-garyan447@gmail.com/T/#u\n[8]  Issue Raised - https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/\n[9]  Git References -\nhttps://git-scm.com/book/en/v2/Git-Internals-Git-References\n[10] Git bisect - https://git-scm.com/docs/git-bisect\n[11] Reftables - https://git-scm.com/docs/reftable\n\n\nThanks & Regards,\nAryan\n"},{"id":"491008","messageId":"CAP8UFD3qf1MW1PkCh7DvwmNoi51sLq4r0Z=K57OCa65WtorAKw@mail.gmail.com","threadId":"61134","inReplyTo":"CAMbn=B4HDXOAThvAmmyA5GEzG1nnvbGvc4yjpg7FHSHQQ-WQfw@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-03-20T11:06:00Z","receivedAt":"2024-03-20T11:06:15Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Sat, Mar 16, 2024 at 7:58 PM Aryan Gupta <garyan447@gmail.com> wrote:\n>\n> Hello everyone.\n>\n> I hope you are doing well. I am writing this email to get a review for\n> my GSoC proposal.\n>\n> Thanks in advance.\n>\n> Regards\n> Aryan\n>\n> Here it goes:\n>\n> -- Refactor git-bisect(1) to make its state self-contained --\n> =============================================================\n>\n> -- Personal Info --\n> ====================\n>\n> Full name :     Aryan Gupta\n> E-mail    :     garyan447@gmail.com\n> Tel       :     (+91) 7018273899\n> Education :     Graphic Era University, Dehradun, India\n> Year      :     Final Year\n> Major     :     Computer Science and Engineering\n> GitHub    :     [1]\n>\n> -- About Me --\n> ====================\n>\n> I have been enthusiastic about open source from the very beginning of\n> my journey as a software developer. I’ve contributed to other\n> open-source projects, though still a beginner, I’m generally familiar\n> with the process of contribution. The related experiences are all in\n> the contribution graph on my GitHub profile page [1]. In the ZAP\n> Project[2] community, I’ve made over 50 PRs [3]. I also participated\n> in the Google Summer of Code 2023 with the OWASP Foundation and\n> successfully completed it as well [4]. I have contributed to some\n> other small projects as well on GitHub.\n\nIt's interesting to know that you have already participated in a GSoC.\nIs there a single blog post about this or more?\n\n> I came to participate in the Git community this year (around\n> February). I got myself rather comfortable with the contribution\n> process by writing, replying, and auditing different sorts of patches\n> in the community.\n>\n> With the patches done so far, I’m getting more familiar with the Git\n> internals, project structures, commonly used APIs, test suites,\n> required tech stacks, and coding guidelines. For understanding better\n> about Git, I read and reread the documentation a few times, including\n> ‘MyFirstContribution.txt’, ‘MyFirstObjectWalk.txt’, and ‘Hacking Git’.\n> The book Pro Git also helped me to understand the Git internals\n> better.\n>\n> Effective communication with mentors is a very important part of\n> Google Summer of Code Program. I know when to ask the right questions\n> and I do every possible thing I can do before asking any question.\n> This trait of mine always proved to be very useful and I believe it\n> will be really beneficial for me for the completion of this GSoC\n> project as well.\n\nOk.\n\n> -- Before GSoC --\n> ====================\n>\n> -- Synopsis --\n> -----------------------\n>\n> I’m picking the project idea “Refactor git-bisect(1) to make its state\n> self-contained” from the SoC 2024 Ideas page [5]. This idea aims to\n> make git-bisect(1) self-contained. Its difficulty should be medium,\n> and the expected project size takes somewhere between 175 hours to 350\n> hours.\n>\n> The git-bisect(1) command is used to find a commit in a range of\n> commits that introduced a specific bug. Starting a bisection run\n> creates a set of state files into the Git repository which record\n> various different parameters like “.git/BISECT_START”. These files\n> look almost like refs due to their names being all-uppercase. This has\n> led to confusion with the new “reftable” backend because it wasn’t\n> quite clear whether those files are in fact refs or not.\n>\n> As it turns out they are not refs and should never be treated like\n> one. Overall, it has been concluded that the way those files are\n> currently stored is not ideal. Instead of having a proliferation of\n> files in the Git directory, it was discussed whether the bisect state\n> should be moved into its own “bisect-state” subdirectory. This would\n> make it more self-contained and thereby avoid future confusion. It is\n> also aligned with the sequencer state used by rebases, which is neatly\n> contained in the “rebase-apply” and “rebase-merge” directories.\n>\n> The goal of this project would be to realize this change. While\n> rearchitecting the layout should be comparatively easy to do, the\n> harder part will be to hash out how to handle backwards compatibility.\n\nIt's Ok to copy the project description, or parts of it, from the idea\npage, but please say that you have done so. This way we can just skip\nthis when we read your proposal.\n\n> -- Benefits to Community --\n> --------------------------------\n>\n> By joining the community and working on this idea, I can collaborate\n> with my mentors and fellow community members to enhance the user\n> experience for those who use git-bisect(1). Additionally, creating a\n> clear distinction between the refs and the git-bisect state files\n> through this project would be highly beneficial for the community.\n>\n> -- Why? --\n> -----------------\n>\n> For me, the biggest question is always why I am doing something. So to\n> answer why I want to contribute to Git in this Google Summer of Code\n> is the learning I will get while communicating with the mentors and\n> the git community. I want to learn as much as I could in this phrase.\n> Also, I want a kick start to begin my journey of contributing to git\n> for a long term. Why I chose git was mainly because I wanted to\n> explore something which is being used by almost every software\n> developer.\n>\n> -- Microproject --\n> ------------------------------\n>\n> - Modernize a test script [6]\n>   - Status: merged into master\n\nPlease add a link to (or the hash of) the commit that merges your\ncommit(s) into the master branch.\n\n>   - Description: Modernize the formatting of the test script to align\n> with current standards and improve its overall readability.\n>   - Remarks: This was my first patch in git which helped me to\n> understand a lot about how the process of submitting a patch and\n> review works.\n>\n> -- Other Patches --\n> ----------------------------\n>\n> Other than the required microproject, I’ve submitted a few other\n> patches when I stumbled upon potential modifications, these patches\n> are:\n>\n> - Zero Count Optimization [7]\n>   - Status: Under Review\n\nLooking at the thread, it seems to me that it has been reviewed and we\nare expecting a reroll from you with at least a better commit message.\n\n>   - Description: Optimize for efficiency using trailing zeros for set\n> bit iteration\n>   - Remarks: This was a great learning task. I learned how tiny things\n> matter and small optimizations might make a big impact on performance.\n>\n>\n> -- In GSoC --\n> ====================\n>\n> -- Plan --\n> ----------------\n>\n> What is Git Bisect?\n>\n> Git Bisect is a git command which helps to find which commit\n> introduced the bug into the codebase at a faster rate by leveraging\n> the power of binary search.\n>\n>\n> The project idea is relatively easy to understand by the description\n> itself. Git bisect stores some state files such as BISECT_START,\n> BISECT_FIRST_PARENT etc which looks very similar to the naming\n> convention used for creating the refs file. Due to this similar naming\n> convention it sometimes causes unexpected results when these state\n> files are confused as the ref files.\n\nI don't think there are unexpected results. I think it's mostly a\nclarification, standardization and cleanup issue.\n\n> In order to fix this problem we can create a new \".git/bisect-state\"\n> directory and store all the state files which belong to the\n> git-bisect(1) command in that directory as proposed by Patrick and\n> store all the files as follows.\n>\n>\n> - BISECT_TERMS -> bisect-state/terms\n> - BISECT_LOG -> bisect-state/log\n> - BISECT_START -> bisect-state/start\n> - BISECT_RUN -> bisect-state/run\n> - BISECT_FIRST_PARENT -> bisect-state/first-parent\n> - BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok\n\nYeah, please link to Patrick's email where he suggests this. And\nplease clarify what is quoted verbatim from his email. It is Ok to\ncopy paste from existing emails, but it helps reviewing proposals if\nyou are clear about this as we can then skip those parts.\n\n> While the change looks very simple, it actually is. We will just\n> update all the paths from where these files are being accessed. When I\n> went through the code of bisect.c file I found that the path is pretty\n> easy to configure we just need to modify it at a few places. The main\n> problem is to efficiently handle the backward compatibility and\n> implement proper test cases to not let the existing things break. I\n> have already gone through the bisect.c file a couple of times just\n> reading and trying to understand all the functions and was able to\n> understand a lot of things about how it works.\n\nThere is \"bisect.c\" and there is \"builtin/bisect.c\". Please make it\nclearer which file(s) you are talking about. Also code examples of how\nyou would update things could be useful.\n\n> -- Challenges with Backward Compatibility --\n> --------------------------------------------\n>\n> I plan to implement a migration mechanism that will detect whether the\n> legacy stat file like BISECT_* are present or not during the\n\nMaybe: s/stat file/status files/\n\n> initialization of git bisect.\n\nWhat do you mean by \"initialization of git bisect\". Does that take\ninto account the fact that users could upgrade while they are\nbisecting? What if they switch back to an older version after\nupgrading?\n\nDo you plan to always check for any \"BISECT_*\" file or would a check\nfor the \"bisect-state\" first would help?\n\n> This migration phase will automatically\n> move these files to the new “.git/bisect-state” directory, ensuring a\n> seamless transition for users while maintaining the compatibility with\n> existing scripts and tools. The biggest challenge is not to let the\n> existing functionality break.\n>\n>\n> -- Strategies for Handling Backward Compatibility --\n> ---------------------------------------------------------\n>\n> 1. Before implementing any changes, a good understanding of how\n> git-bisect works and how it is structured is very important. So, I\n> will thoroughly analyze the existing usage patterns of git-bisect and\n> list down all the potential areas of impact.\n>\n> 2. To validate the codebase changes and ensure the stability and the\n> backward compatibility of git-bisect command. I will write unit tests\n> for all the required changes.\n\nDo you mean unit tests using the new unit test framework in C. Could\nyou show an example?\n\n> 3. I will also try to create some real scenarios where I will be\n> manually testing the desired behavior.\n>\n> 4. We might also need some regression tests to test some of the\n> functionality which can't be tested using unit tests.\n\nIn which test script would you add them?\n\n> Here is a list of a few tests which I am able to think of as of now:\n>\n> 1. Verify correct relocation of state files during initialization.\n> 2. Test compatibility with existing bisect scripts and tools.\n> 3. Validate handling of edge cases, such as empty or corrupted state\n> files, to prevent unexpected behavior\n>\n> I am pretty sure I am still missing some of the problems which I may\n> face in the future but I will figure them out too when they arrive.\n>\n> -- Timeline --\n> ------------------\n>\n> I will be starting the project as soon as I receive the confirmation\n> of my proposal getting selected for GSoC.\n>\n> Here is a list of phases during the GSoC period for this project.\n> While these are just the approximations, the actual timeline may vary\n> because of the review iterations or unpredictable scenarios.\n>\n> 1. Understanding the existing implementation of Bisect command\n>     - This includes understanding how to test the changes locally\n> which are made in the bisect command efficiently\n>     - Get more familiar with the style of writing the code\n>\n> 2. Start working on the task to add the directory\n>     - Updating all the references wherever these bisect files are used\n>     - Writing/Updating tests to test all the changes made\n>\n> 3. Start with supporting backward compatibility\n>     - For this phase what I am thinking is of adding a stage just\n> after the initialization of git bisect command which will detect if\n> there exist some files by the name BISECT_* and migrate all those\n> files into the “.git/bisect” directory.\n>\n> 4. Adding Tests\n>     - Through testing for backward compatibility is very very\n> important so that the changes don’t break the existing changes.\n>\n> 5. Documenting the changes\n>     - This might also go side by side if mentors need some weekly\n> documentation of the tasks done.\n\nTests and documentation should be part of the patches that change the\nbehavior. So it doesn't really make sense to list them separately in\nthe timeline.\n\n> -- Availability --\n> ----------------------\n>\n> I will be able to contribute 2-3 hours on weekdays and minimum 6 hours\n> on weekends. Which gives me around 22-27 hours per week to work on the\n> project. I will work till a minimum span of 14 weeks (can be extended)\n> during the GSoC. I will try my best to keep this time commitment and\n> be always available through the community’s mailing list. Also, I have\n> exams in the first week of June so I will have limited availability\n> during that period. The project might take somewhere around 175-350\n> hours.\n\nThanks for these details related to your availability. As this is your\nfinal year, when are you expecting to graduate?\n\n> -- After GSoC --\n> ---------------------\n>\n> After GSoC I intend to be a part of the community and keep\n> contributing to the git’s codebase. I eagerly want to learn a lot from\n> the git community and enhance my skills. I also see myself making\n> important contributions to git in the future.\n>\n> When I first joined the community 2 months ago, the ancient way of\n> collaborating through a mailing list by sending diff patches was\n> really puzzling (GitHub was the only means that I knew about for\n> open-source collaboration). After sending a patch I got a little\n> comfortable with it and started loving it.\n>\n> -- Closing remarks --\n> ----------------------------\n>\n> I am really enthusiastic to contribute to git. I really want to learn\n> a lot from my mentors and the whole git community. Everyone\n> contributes using git, why not contribute to git :).\n>\n> In the end I really want to thank the whole community, especially\n> Christian and Junio, for their valuable time in reviewing my patches\n> and guiding me with the problems I faced.\n\nThanks for your proposal. Please make sure you submit it soon as a pdf\nfile to the GSoC website. It can then be updated by uploading a new\npdf until the April 2 1800 UTC deadline.\n"},{"id":"491127","messageId":"ZfwsnMWg12S2gV3C@tanuki","threadId":"61134","inReplyTo":"CAMbn=B4HDXOAThvAmmyA5GEzG1nnvbGvc4yjpg7FHSHQQ-WQfw@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-21T12:48:28Z","receivedAt":"2024-03-21T12:48:34Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sat, Mar 16, 2024 at 07:57:49PM +0100, Aryan Gupta wrote:\n[snip]\n> -- Plan --\n> ----------------\n> \n> What is Git Bisect?\n> \n> Git Bisect is a git command which helps to find which commit\n> introduced the bug into the codebase at a faster rate by leveraging\n> the power of binary search.\n> \n> \n> The project idea is relatively easy to understand by the description\n> itself. Git bisect stores some state files such as BISECT_START,\n> BISECT_FIRST_PARENT etc which looks very similar to the naming\n> convention used for creating the refs file. Due to this similar naming\n> convention it sometimes causes unexpected results when these state\n> files are confused as the ref files.\n> \n> In order to fix this problem we can create a new \".git/bisect-state\"\n> directory and store all the state files which belong to the\n> git-bisect(1) command in that directory as proposed by Patrick and\n> store all the files as follows.\n> \n> \n> - BISECT_TERMS -> bisect-state/terms\n> - BISECT_LOG -> bisect-state/log\n> - BISECT_START -> bisect-state/start\n> - BISECT_RUN -> bisect-state/run\n> - BISECT_FIRST_PARENT -> bisect-state/first-parent\n> - BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok\n> \n> While the change looks very simple, it actually is. We will just\n> update all the paths from where these files are being accessed. When I\n> went through the code of bisect.c file I found that the path is pretty\n> easy to configure we just need to modify it at a few places. The main\n> problem is to efficiently handle the backward compatibility and\n> implement proper test cases to not let the existing things break. I\n> have already gone through the bisect.c file a couple of times just\n> reading and trying to understand all the functions and was able to\n> understand a lot of things about how it works.\n\nAs you also mention further down in the section about backwards\ncompatibility, the challenge of this project is not about doing those\nchanges. That indeed is the trivial part of this whole project.\n\nThe real challenge is figuring out with the community how to ensure that\nthe change is indeed backwards compatible, and that does not only\ninvolve backwards compatibility with Git itself, but also with other,\nthird party tools. The biggest question will be whether the refactoring\nis ultimately going to be worth it in the bigger picture, or whether we\nshould really just leave it be.\n\nSo personally, I rather see the biggest part of this project to find\ngood middle ground with the community. It's thus of a more \"political\"\nnature overall.\n\nI don't mean to discourage you with this. I just want to state up front\nwhere you should expect difficulties so that you don't underestimate the\ndifficulty of this project overall. It could very well happen that the\nwhole idea gets shot down by the community in case we figure out that it\nis simply too risky and/or not worth it in the long run.\n\nIf you want to stick with this idea then I would strongly recommend that\nyou mention this in your proposal.\n\nPatrick\n"},{"id":"491137","messageId":"CAMbn=B58_KSvkEMEsCnrN6rGL61+qFv9NqcOO8adyU5A37=vjQ@mail.gmail.com","threadId":"61134","inReplyTo":"CAP8UFD3qf1MW1PkCh7DvwmNoi51sLq4r0Z=K57OCa65WtorAKw@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Aryan Gupta","fromEmail":"garyan447@gmail.com","sentAt":"2024-03-21T13:21:33Z","receivedAt":"2024-03-21T13:21:46Z","isPatch":false,"sender":{"key":"garyan447@gmail.com","avatar":"https://avatars.githubusercontent.com/u/87857234?v=4"},"body":"Hey Christian\n\nThank you for reviewing the proposal.\n\nOn Wed, Mar 20, 2024 at 12:06 PM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi,\n>\n> On Sat, Mar 16, 2024 at 7:58 PM Aryan Gupta <garyan447@gmail.com> wrote:\n> >\n> > Hello everyone.\n> >\n> > I hope you are doing well. I am writing this email to get a review for\n> > my GSoC proposal.\n> >\n> > Thanks in advance.\n> >\n> > Regards\n> > Aryan\n> >\n> > Here it goes:\n> >\n> > -- Refactor git-bisect(1) to make its state self-contained --\n> > =============================================================\n> >\n> > -- Personal Info --\n> > ====================\n> >\n> > Full name :     Aryan Gupta\n> > E-mail    :     garyan447@gmail.com\n> > Tel       :     (+91) 7018273899\n> > Education :     Graphic Era University, Dehradun, India\n> > Year      :     Final Year\n> > Major     :     Computer Science and Engineering\n> > GitHub    :     [1]\n> >\n> > -- About Me --\n> > ====================\n> >\n> > I have been enthusiastic about open source from the very beginning of\n> > my journey as a software developer. I’ve contributed to other\n> > open-source projects, though still a beginner, I’m generally familiar\n> > with the process of contribution. The related experiences are all in\n> > the contribution graph on my GitHub profile page [1]. In the ZAP\n> > Project[2] community, I’ve made over 50 PRs [3]. I also participated\n> > in the Google Summer of Code 2023 with the OWASP Foundation and\n> > successfully completed it as well [4]. I have contributed to some\n> > other small projects as well on GitHub.\n>\n> It's interesting to know that you have already participated in a GSoC.\n> Is there a single blog post about this or more?\n\nHere it is: https://www.zaproxy.org/blog/2023-09-11-browser-recorder/\n\n> > I came to participate in the Git community this year (around\n> > February). I got myself rather comfortable with the contribution\n> > process by writing, replying, and auditing different sorts of patches\n> > in the community.\n> >\n> > With the patches done so far, I’m getting more familiar with the Git\n> > internals, project structures, commonly used APIs, test suites,\n> > required tech stacks, and coding guidelines. For understanding better\n> > about Git, I read and reread the documentation a few times, including\n> > ‘MyFirstContribution.txt’, ‘MyFirstObjectWalk.txt’, and ‘Hacking Git’.\n> > The book Pro Git also helped me to understand the Git internals\n> > better.\n> >\n> > Effective communication with mentors is a very important part of\n> > Google Summer of Code Program. I know when to ask the right questions\n> > and I do every possible thing I can do before asking any question.\n> > This trait of mine always proved to be very useful and I believe it\n> > will be really beneficial for me for the completion of this GSoC\n> > project as well.\n>\n> Ok.\n>\n> > -- Before GSoC --\n> > ====================\n> >\n> > -- Synopsis --\n> > -----------------------\n> >\n> > I’m picking the project idea “Refactor git-bisect(1) to make its state\n> > self-contained” from the SoC 2024 Ideasb page [5]. This idea aims to\n> > make git-bisect(1) self-contained. Its difficulty should be medium,\n> > and the expected project size takes somewhere between 175 hours to 350\n> > hours.\n> >\n> > The git-bisect(1) command is used to find a commit in a range of\n> > commits that introduced a specific bug. Starting a bisection run\n> > creates a set of state files into the Git repository which record\n> > various different parameters like “.git/BISECT_START”. These files\n> > look almost like refs due to their names being all-uppercase. This has\n> > led to confusion with the new “reftable” backend because it wasn’t\n> > quite clear whether those files are in fact refs or not.\n> >\n> > As it turns out they are not refs and should never be treated like\n> > one. Overall, it has been concluded that the way those files are\n> > currently stored is not ideal. Instead of having a proliferation of\n> > files in the Git directory, it was discussed whether the bisect state\n> > should be moved into its own “bisect-state” subdirectory. This would\n> > make it more self-contained and thereby avoid future confusion. It is\n> > also aligned with the sequencer state used by rebases, which is neatly\n> > contained in the “rebase-apply” and “rebase-merge” directories.\n> >\n> > The goal of this project would be to realize this change. While\n> > rearchitecting the layout should be comparatively easy to do, the\n> > harder part will be to hash out how to handle backwards compatibility.\n>\n> It's Ok to copy the project description, or parts of it, from the idea\n> page, but please say that you have done so. This way we can just skip\n> this when we read your proposal.\n>\nOkay.\n\n> > -- Benefits to Community --\n> > --------------------------------\n> >\n> > By joining the community and working on this idea, I can collaborate\n> > with my mentors and fellow community members to enhance the user\n> > experience for those who use git-bisect(1). Additionally, creating a\n> > clear distinction between the refs and the git-bisect state files\n> > through this project would be highly beneficial for the community.\n> >\n> > -- Why? --\n> > -----------------\n> >\n> > For me, the biggest question is always why I am doing something. So to\n> > answer why I want to contribute to Git in this Google Summer of Code\n> > is the learning I will get while communicating with the mentors and\n> > the git community. I want to learn as much as I could in this phrase.\n> > Also, I want a kick start to begin my journey of contributing to git\n> > for a long term. Why I chose git was mainly because I wanted to\n> > explore something which is being used by almost every software\n> > developer.\n> >\n> > -- Microproject --\n> > ------------------------------\n> >\n> > - Modernize a test script [6]\n> >   - Status: merged into master\n>\n> Please add a link to (or the hash of) the commit that merges your\n> commit(s) into the master branch.\n>\nHere it is: https://github.com/gitgitgadget/git/commit/06ac51898156b7bba0a42d36731285ec3c1975aa\nwill add it the next version as well.\n> >   - Description: Modernize the formatting of the test script to align\n> > with current standards and improve its overall readability.\n> >   - Remarks: This was my first patch in git which helped me to\n> > understand a lot about how the process of submitting a patch and\n> > review works.\n> >\n> > -- Other Patches --\n> > ----------------------------\n> >\n> > Other than the required microproject, I’ve submitted a few other\n> > patches when I stumbled upon potential modifications, these patches\n> > are:\n> >\n> > - Zero Count Optimization [7]\n> >   - Status: Under Review\n>\n> Looking at the thread, it seems to me that it has been reviewed and we\n> are expecting a reroll from you with at least a better commit message.\n\nYeah I am still working on the task which Junio suggested to me to do,\nwhich is to only use the builtin function if there is support for it\non the machine.\n.\n>\n> >   - Description: Optimize for efficiency using trailing zeros for set\n> > bit iteration\n> >   - Remarks: This was a great learning task. I learned how tiny things\n> > matter and small optimizations might make a big impact on performance.\n> >\n> >\n> > -- In GSoC --\n> > ====================\n> >\n> > -- Plan --\n> > ----------------\n> >\n> > What is Git Bisect?\n> >\n> > Git Bisect is a git command which helps to find which commit\n> > introduced the bug into the codebase at a faster rate by leveraging\n> > the power of binary search.\n> >\n> >\n> > The project idea is relatively easy to understand by the description\n> > itself. Git bisect stores some state files such as BISECT_START,\n> > BISECT_FIRST_PARENT etc which looks very similar to the naming\n> > convention used for creating the refs file. Due to this similar naming\n> > convention it sometimes causes unexpected results when these state\n> > files are confused as the ref files.\n>\n> I don't think there are unexpected results. I think it's mostly a\n> clarification, standardization and cleanup issue.\n\nOkay. Thank you for the clarification.\n>\n> > In order to fix this problem we can create a new \".git/bisect-state\"\n> > directory and store all the state files which belong to the\n> > git-bisect(1) command in that directory as proposed by Patrick and\n> > store all the files as follows.\n> >\n> >\n> > - BISECT_TERMS -> bisect-state/terms\n> > - BISECT_LOG -> bisect-state/log\n> > - BISECT_START -> bisect-state/start\n> > - BISECT_RUN -> bisect-state/run\n> > - BISECT_FIRST_PARENT -> bisect-state/first-parent\n> > - BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok\n>\n> Yeah, please link to Patrick's email where he suggests this. And\n> please clarify what is quoted verbatim from his email. It is Ok to\n> copy paste from existing emails, but it helps reviewing proposals if\n> you are clear about this as we can then skip those parts.\n>\nOkay sure.\n\n> > While the change looks very simple, it actually is. We will just\n> > update all the paths from where these files are being accessed. When I\n> > went through the code of bisect.c file I found that the path is pretty\n> > easy to configure we just need to modify it at a few places. The main\n> > problem is to efficiently handle the backward compatibility and\n> > implement proper test cases to not let the existing things break. I\n> > have already gone through the bisect.c file a couple of times just\n> > reading and trying to understand all the functions and was able to\n> > understand a lot of things about how it works.\n>\n> There is \"bisect.c\" and there is \"builtin/bisect.c\". Please make it\n> clearer which file(s) you are talking about. Also code examples of how\n> you would update things could be useful.\n>\nI am talking about \"bisect.c\" here. But this path update needs to be\ndone in both of the files i.e. \"bisect.c\" and \"builtin/bisect.c\" as shown\nbelow. Also, As I again went through the codebase I found that these\npaths are being used at some other places as well such as the test files,\nwt-status.c file and a few more.\n\ndiff --git a/bisect.c b/bisect.c\nindex 60aae2fe50..d615113c73 100644\n--- a/bisect.c\n+++ b/bisect.c\n@@ -472,13 +472,13 @@ static int read_bisect_refs(void)\n        return for_each_ref_in(\"refs/bisect/\", register_ref, NULL);\n }\n\n-static GIT_PATH_FUNC(git_path_bisect_names, \"BISECT_NAMES\")\n-static GIT_PATH_FUNC(git_path_bisect_ancestors_ok, \"BISECT_ANCESTORS_OK\")\n-static GIT_PATH_FUNC(git_path_bisect_run, \"BISECT_RUN\")\n-static GIT_PATH_FUNC(git_path_bisect_start, \"BISECT_START\")\n-static GIT_PATH_FUNC(git_path_bisect_log, \"BISECT_LOG\")\n-static GIT_PATH_FUNC(git_path_bisect_terms, \"BISECT_TERMS\")\n-static GIT_PATH_FUNC(git_path_bisect_first_parent, \"BISECT_FIRST_PARENT\")\n+static GIT_PATH_FUNC(git_path_bisect_names, \"bisect-state/BISECT_NAMES\")\n+static GIT_PATH_FUNC(git_path_bisect_ancestors_ok,\n\"bisect-state/BISECT_ANCESTORS_OK\")\n+static GIT_PATH_FUNC(git_path_bisect_run, \"bisect-state/BISECT_RUN\")\n+static GIT_PATH_FUNC(git_path_bisect_start, \"bisect-state/BISECT_START\")\n+static GIT_PATH_FUNC(git_path_bisect_log, \"bisect-state/BISECT_LOG\")\n+static GIT_PATH_FUNC(git_path_bisect_terms, \"bisect-state/BISECT_TERMS\")\n+static GIT_PATH_FUNC(git_path_bisect_first_parent,\n\"bisect-state/BISECT_FIRST_PARENT\")\n\nNote that this is just an example I will not be removing the existing paths\ninstead I will be adding new paths to keep both backward and forward\ncompatibility. I will update all the writes in state files with both the paths\nand all the reads with first a check for bisect_state directory and then\nread from bisect state directory if it is present else first migrate from\n.git directory and then read.\n\n> > -- Challenges with Backward Compatibility --\n> > --------------------------------------------\n> >\n> > I plan to implement a migration mechanism that will detect whether the\n> > legacy stat file like BISECT_* are present or not during the\n>\n> Maybe: s/stat file/status files/\n>\nOops, I mean state files used to store bisect state which can be find in\n.git directory\n\n> > initialization of git bisect.\n>\n> What do you mean by \"initialization of git bisect\". Does that take\n> into account the fact that users could upgrade while they are\n> bisecting? What if they switch back to an older version after\n> upgrading?\n>\n\n\"Initialization\" for now is an abstract concept for me in my mind,\nwhich I think is the phase just after when the git bisect command\nis run by the user and before the actual execution of git bisect. But\nthinking about the scenario that a user can upgrade while bisecting.\nI think it won't be enough. So do you think we can add this migration\nstep every time the bisect state files are accessed. Also to address\nthe issue of switching back to an older version, we will not delete\nthe older files? And instead what I am thinking is that we will end up\nmaintaining the state files at two places one in .git directory and other\nin .git/bisect-state.\n\nAnd do you have a solution for when we will be able to completely\nremove the state files in the .git directory?\n\n> Do you plan to always check for any \"BISECT_*\" file or would a check\n> for the \"bisect-state\" first would help?\n>\n\nI think checking for bisect-state will be better because we will be maintaining\nthe files in both the directories.\n\n> > This migration phase will automatically\n> > move these files to the new “.git/bisect-state” directory, ensuring a\n> > seamless transition for users while maintaining the compatibility with\n> > existing scripts and tools. The biggest challenge is not to let the\n> > existing functionality break.\n> >\n> >\n> > -- Strategies for Handling Backward Compatibility --\n> > ---------------------------------------------------------\n> >\n> > 1. Before implementing any changes, a good understanding of how\n> > git-bisect works and how it is structured is very important. So, I\n> > will thoroughly analyze the existing usage patterns of git-bisect and\n> > list down all the potential areas of impact.\n> >\n> > 2. To validate the codebase changes and ensure the stability and the\n> > backward compatibility of git-bisect command. I will write unit tests\n> > for all the required changes.\n>\n> Do you mean unit tests using the new unit test framework in C. Could\n> you show an example?\n>\n\nNot sure about what is the standard way that git uses for writing unit tests.\nCould you tell me a bit about this?\n\n> > 3. I will also try to create some real scenarios where I will be\n> > manually testing the desired behavior.\n> >\n> > 4. We might also need some regression tests to test some of the\n> > functionality which can't be tested using unit tests.\n>\n> In which test script would you add them?\n\nI will be writing these in bash and will be adding it in a new test case file\ninside the git/t directory or maybe in \"git\\t\\t6030-bisect-porcelain.sh\"\nfile. I will try mocking a scenario where we have the BISECT_* files available\nin the .git directory and then run git bisect using the command line and then\ncheck the expected results.\n\n>\n> > Here is a list of a few tests which I am able to think of as of now:\n> >\n> > 1. Verify correct relocation of state files during initialization.\n> > 2. Test compatibility with existing bisect scripts and tools.\n> > 3. Validate handling of edge cases, such as empty or corrupted state\n> > files, to prevent unexpected behavior\n> >\n> > I am pretty sure I am still missing some of the problems which I may\n> > face in the future but I will figure them out too when they arrive.\n> >\n> > -- Timeline --\n> > ------------------\n> >\n> > I will be starting the project as soon as I receive the confirmation\n> > of my proposal getting selected for GSoC.\n> >\n> > Here is a list of phases during the GSoC period for this project.\n> > While these are just the approximations, the actual timeline may vary\n> > because of the review iterations or unpredictable scenarios.\n> >\n> > 1. Understanding the existing implementation of Bisect command\n> >     - This includes understanding how to test the changes locally\n> > which are made in the bisect command efficiently\n> >     - Get more familiar with the style of writing the code\n> >\n> > 2. Start working on the task to add the directory\n> >     - Updating all the references wherever these bisect files are used\n> >     - Writing/Updating tests to test all the changes made\n> >\n> > 3. Start with supporting backward compatibility\n> >     - For this phase what I am thinking is of adding a stage just\n> > after the initialization of git bisect command which will detect if\n> > there exist some files by the name BISECT_* and migrate all those\n> > files into the “.git/bisect” directory.\n> >\n> > 4. Adding Tests\n> >     - Through testing for backward compatibility is very very\n> > important so that the changes don’t break the existing changes.\n> >\n> > 5. Documenting the changes\n> >     - This might also go side by side if mentors need some weekly\n> > documentation of the tasks done.\n>\n> Tests and documentation should be part of the patches that change the\n> behavior. So it doesn't really make sense to list them separately in\n> the timeline.\n\nOkay. Maybe a blog post could be a part of this?\n\n>\n> > -- Availability --\n> > ----------------------\n> >\n> > I will be able to contribute 2-3 hours on weekdays and minimum 6 hours\n> > on weekends. Which gives me around 22-27 hours per week to work on the\n> > project. I will work till a minimum span of 14 weeks (can be extended)\n> > during the GSoC. I will try my best to keep this time commitment and\n> > be always available through the community’s mailing list. Also, I have\n> > exams in the first week of June so I will have limited availability\n> > during that period. The project might take somewhere around 175-350\n> > hours.\n>\n> Thanks for these details related to your availability. As this is your\n> final year, when are you expecting to graduate?\n\nI will be graduating in July this year.\n\n>\n> > -- After GSoC --\n> > ---------------------\n> >\n> > After GSoC I intend to be a part of the community and keep\n> > contributing to the git’s codebase. I eagerly want to learn a lot from\n> > the git community and enhance my skills. I also see myself making\n> > important contributions to git in the future.\n> >\n> > When I first joined the community 2 months ago, the ancient way of\n> > collaborating through a mailing list by sending diff patches was\n> > really puzzling (GitHub was the only means that I knew about for\n> > open-source collaboration). After sending a patch I got a little\n> > comfortable with it and started loving it.\n> >\n> > -- Closing remarks --\n> > ----------------------------\n> >\n> > I am really enthusiastic to contribute to git. I really want to learn\n> > a lot from my mentors and the whole git community. Everyone\n> > contributes using git, why not contribute to git :).\n> >\n> > In the end I really want to thank the whole community, especially\n> > Christian and Junio, for their valuable time in reviewing my patches\n> > and guiding me with the problems I faced.\n>\n> Thanks for your proposal. Please make sure you submit it soon as a pdf\n> file to the GSoC website. It can then be updated by uploading a new\n> pdf until the April 2 1800 UTC deadline.\n\nOkay. Sure, I will share an updated proposal as soon as possible.\n"},{"id":"491139","messageId":"CAMbn=B73ioQ8oRucG4X8anhwrnbhJRky7BSe7DKpQad85Dt5xg@mail.gmail.com","threadId":"61134","inReplyTo":"ZfwsnMWg12S2gV3C@tanuki","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Aryan Gupta","fromEmail":"garyan447@gmail.com","sentAt":"2024-03-21T13:27:56Z","receivedAt":"2024-03-21T13:28:08Z","isPatch":false,"sender":{"key":"garyan447@gmail.com","avatar":"https://avatars.githubusercontent.com/u/87857234?v=4"},"body":"On Thu, Mar 21, 2024 at 1:48 PM Patrick Steinhardt <ps@pks.im> wrote:\n>\n> On Sat, Mar 16, 2024 at 07:57:49PM +0100, Aryan Gupta wrote:\n> [snip]\n> > -- Plan --\n> > ----------------\n> >\n> > What is Git Bisect?\n> >\n> > Git Bisect is a git command which helps to find which commit\n> > introduced the bug into the codebase at a faster rate by leveraging\n> > the power of binary search.\n> >\n> >\n> > The project idea is relatively easy to understand by the description\n> > itself. Git bisect stores some state files such as BISECT_START,\n> > BISECT_FIRST_PARENT etc which looks very similar to the naming\n> > convention used for creating the refs file. Due to this similar naming\n> > convention it sometimes causes unexpected results when these state\n> > files are confused as the ref files.\n> >\n> > In order to fix this problem we can create a new \".git/bisect-state\"\n> > directory and store all the state files which belong to the\n> > git-bisect(1) command in that directory as proposed by Patrick and\n> > store all the files as follows.\n> >\n> >\n> > - BISECT_TERMS -> bisect-state/terms\n> > - BISECT_LOG -> bisect-state/log\n> > - BISECT_START -> bisect-state/start\n> > - BISECT_RUN -> bisect-state/run\n> > - BISECT_FIRST_PARENT -> bisect-state/first-parent\n> > - BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok\n> >\n> > While the change looks very simple, it actually is. We will just\n> > update all the paths from where these files are being accessed. When I\n> > went through the code of bisect.c file I found that the path is pretty\n> > easy to configure we just need to modify it at a few places. The main\n> > problem is to efficiently handle the backward compatibility and\n> > implement proper test cases to not let the existing things break. I\n> > have already gone through the bisect.c file a couple of times just\n> > reading and trying to understand all the functions and was able to\n> > understand a lot of things about how it works.\n>\n> As you also mention further down in the section about backwards\n> compatibility, the challenge of this project is not about doing those\n> changes. That indeed is the trivial part of this whole project.\n>\nYes.\n\n> The real challenge is figuring out with the community how to ensure that\n> the change is indeed backwards compatible, and that does not only\n> involve backwards compatibility with Git itself, but also with other,\n> third party tools. The biggest question will be whether the refactoring\n> is ultimately going to be worth it in the bigger picture, or whether we\n> should really just leave it be.\n>\nYeah. As mentioned in my previous email even I afraid about we will be\nending with managing the bisect files at two places in order to ensure\nbackward compatibility.\n\n> So personally, I rather see the biggest part of this project to find\n> good middle ground with the community. It's thus of a more \"political\"\n> nature overall.\n>\nYes I think we can figure it out together as a community what should be\ndone to encounter this problem.\n\n> I don't mean to discourage you with this. I just want to state up front\n> where you should expect difficulties so that you don't underestimate the\n> difficulty of this project overall. It could very well happen that the\n> whole idea gets shot down by the community in case we figure out that it\n> is simply too risky and/or not worth it in the long run.\n>\nYes, it's true.\n\n> If you want to stick with this idea then I would strongly recommend that\n> you mention this in your proposal.\n>\nI am open to changing to another idea, I won't mind that. Because my\nultimate aim to add something (even it's a small patch) to git and if\nthis project will never be in use. I am willing to change it. Let me know\nwhat you think about it.\n\n> Patrick\n"},{"id":"491147","messageId":"ZfxGp6p6RiS5i5SD@tanuki","threadId":"61134","inReplyTo":"CAMbn=B73ioQ8oRucG4X8anhwrnbhJRky7BSe7DKpQad85Dt5xg@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-21T14:39:35Z","receivedAt":"2024-03-21T14:39:41Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Mar 21, 2024 at 02:27:56PM +0100, Aryan Gupta wrote:\n> On Thu, Mar 21, 2024 at 1:48 PM Patrick Steinhardt <ps@pks.im> wrote:\n[snip]\n> > If you want to stick with this idea then I would strongly recommend that\n> > you mention this in your proposal.\n> >\n> I am open to changing to another idea, I won't mind that. Because my\n> ultimate aim to add something (even it's a small patch) to git and if\n> this project will never be in use. I am willing to change it. Let me know\n> what you think about it.\n\nI'll leave it up to you to pick the project you're most interested in. I\nonly want to ensure that you have as much information as required to do\na proper assessment of the different proposed projects. So if you want\nto stick to the idea then that's fine. If you want to switch now, then\nthat is fine, too.\n\nPatrick\n"},{"id":"491301","messageId":"CAMbn=B6ScMB32uds-OK9uRCfVHy7nx9=J8R9=J8Jink3m38-zQ@mail.gmail.com","threadId":"61134","inReplyTo":"CAP8UFD3qf1MW1PkCh7DvwmNoi51sLq4r0Z=K57OCa65WtorAKw@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Aryan Gupta","fromEmail":"garyan447@gmail.com","sentAt":"2024-03-23T16:37:41Z","receivedAt":"2024-03-23T16:37:54Z","isPatch":false,"sender":{"key":"garyan447@gmail.com","avatar":"https://avatars.githubusercontent.com/u/87857234?v=4"},"body":"Hello mentors\n\nHere is the next version of my proposal. I had a problem changing the\nsubject of the mail while keeping the email in the same thread. So sending\nit here only.\nGoogle doc link:\nhttps://docs.google.com/document/d/1MRmGpJeUdrp1HfizyI7p1oSGVuOUQL2WEmV7x6\nYZ0Is/edit?usp=sharing\n\nGSoC Proposal V2\n\n*******************************************************\nRefactor git-bisect(1) to make its state self-contained\n******************************************************\n\n\n*************\nPersonal Info\n*************\n\nFull name    :     Aryan Gupta\nE-mail        :     garyan447@gmail.com\nTel        :     (+91) 7018273899\nEducation    :     Graphic Era University, Dehradun, India\nYear        :     Final Year\nMajor        :     Computer Science and Engineering\nGitHub        :     https://github.com/aryangupta701\n\n\n********\nAbout Me\n********\n\nI have been enthusiastic about open source from the very beginning of my\njourney as a software developer. I’ve contributed to other open-source\nprojects, though still a beginner, I’m generally familiar with the process\nof contribution. The related experiences are all in the contribution graph\non my GitHub profile page[1]. In the ZAP Project[2] community, I’ve made\nover 50 PRs[3]. I also participated in the Google Summer of Code 2023 with\nthe OWASP Foundation and successfully completed it as well (Project Link\n[4]). I am still one of the active extended team members to contribute to\nthe ZAP. I have contributed to some small projects as well on github.\n\nI came to participate in the Git community this year (around February). I\ngot myself rather comfortable with the contribution process by writing,\nreplying, and auditing different sorts of patches in the community.\n\nWith the patches done so far, I’m getting more familiar with the Git\ninternals, project structures, commonly used APIs, test suites, required\ntech stacks, and coding guidelines. For understanding better about Git, I\nread and reread the documentation a few times, including\n‘MyFirstContribution.txt’, ‘MyFirstObjectWalk.txt’, and ‘Hacking Git’. The\nbook Pro Git also helped me to understand the Git internals better.\n\nEffective communication with mentors is a very important part of Google\nSummer of Code Program. I know when to ask the right questions and I do\nevery possible thing I can do before asking any question. This trait of\nmine always proves to be very useful and I believe it will be really\nbeneficial for me for completing this GSoC project as well.\n\n\n***********\nBefore GSoC\n***********\n\nSynopsis (copied from the idea lists page)\n*****************************************\n\nI’m picking the project idea “Refactor git-bisect(1) to make its state\nself-contained” from the SoC 2024 Ideas[5] page. This idea aims to make\ngit-bisect(1) self contained. Its difficulty should be medium, and the\nexpected project size takes somewhere between 175 hours to 350 hours.\n\nThe git-bisect(1) command is used to find a commit in a range of commits\nthat introduced a specific bug. Starting a bisection run creates a set of\nstate files into the Git repository which record various different\nparameters like “.git/BISECT_START”. These files look almost like refs due\nto their names being all-uppercase. This has led to confusion with the new\n“reftable” backend because it wasn’t quite clear whether those files are\nin fact refs or not.\n\nAs it turns out they are not refs and should never be treated like one.\nOverall, it has been concluded that the way those files are currently\nstored is not ideal. Instead of having a proliferation of files in the Git\ndirectory, it was discussed whether the bisect state should be moved into\nits own “bisect-state” subdirectory. This would make it more\nself-contained and thereby avoid future confusion. It is also aligned with\nthe sequencer state used by rebases, which is neatly contained in the\n“rebase-apply” and “rebase-merge” directories.\n\nThe goal of this project would be to realize this change. While\nrearchitecting the layout should be comparatively easy to do, the harder\npart will be to hash out how to handle backwards compatibility.\n\nBenefits to Community\n********************\n\nBy joining the community and working on this idea, I can collaborate with\nmy mentors and fellow community members to enhance the user experience for\nthose who use git-bisect(1). Additionally, creating a clear distinction\nbetween the refs and the git-bisect state files through this project would\nbe highly beneficial for the community.\n\nWhy?\n***\n\nFor me the biggest question is always why I am doing something. So to\nanswer why I want to contribute to Git in this Google summer of code is\nthe learning I will get while communicating with the mentors and the git\ncommunity. I was to learn as much as I could in this phrase. Also, I want\na kick start to begin my journey of contributing to git for a long term.\nWhy I chose git was mainly because I wanted to explore something which is\nbeing used by almost every software developer.\n\nMicroproject\n***********\n\nModernize a test script [6]\nStatus: merged into master (Hash Link [7])\nDescription: Modernize the formatting of the test script to align with\ncurrent\nstandards and improve its overall readability.\nRemarks: This was my first patch in git which helped me to understand a\nlot about how the process of submitting a patch and review works.\n\nOther Patches\n*************\n\nOther than the required microproject, I’ve submitted a few other patches\nwhen I stumbled upon potential modifications, these patches are:\n\nZero Count Optimization [8]\nStatus: Work in Progress for second version\nDescription: Optimize for efficiency using trailing zeros for set bit\niteration\nRemarks: This was a great learning task. I learned how tiny things matter\nand small optimizations might make a big impact on performance.\n\n\n*******\nIn GSoC\n*******\n\nPlan\n****\n\nWhat is Git Bisect?\n\nGit Bisect is a git command which helps to find which commit introduced\nthe bug into the codebase at a faster rate by leveraging the power of\nbinary search.\n\n\nThe project idea is relatively easy to understand by the description\nitself. Git bisect stores some state files such as BISECT_START,\nBISECT_FIRST_PARENT etc which looks very similar to the naming convention\nused for creating the refs file.These files, resembling refs with their\nall-uppercase naming convention, have caused confusion, particularly with\nthe introduction of the new “reftable” backend. It's unclear whether these\nfiles are indeed refs. Hence, this project seeks to redefine the storage\napproach for these files within the git repository.\n\nIn order to fix this problem we can create a new \".git/bisect-state\"\ndirectory and store all the state files which belong to the git-bisect(1)\ncommand in that directory as proposed by Patrick (issue link [9]) and\nstore all the files as follows.\n\n\n\n- BISECT_TERMS -> bisect-state/terms\n- BISECT_LOG -> bisect-state/log\n- BISECT_START -> bisect-state/start\n- BISECT_RUN -> bisect-state/run\n- BISECT_FIRST_PARENT -> bisect-state/first-parent\n- BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok\n\nWhile the change looks very simple, it actually is. We will just update\nall the paths from where these files are being accessed. When I went\nthrough the code of “bisect.c” and “builtin/bisect.c” files. I found that\nthe path is pretty easy to configure; we just need to modify it in a few\nplaces. Also, I found that these paths are being used at some other places\nas well such as the test files,”wt-status.c” file and a few more. The main\nproblem is to efficiently handle the backward compatibility and implement\nproper test cases to not let the existing things break. I have already\ngone through the bisect.c file a couple of times just reading and trying\nto understand all the functions and was able to understand a lot of things\nabout how it works. Here is an example of the code changes which I am\ntalking about.\n\n\n    diff --git a/bisect.c b/bisect.c\nindex 60aae2fe50..d615113c73 100644\n--- a/bisect.c\n+++ b/bisect.c\n@@ -472,13 +472,13 @@ static int read_bisect_refs(void)\n        return for_each_ref_in(\"refs/bisect/\"\n, register_ref, NULL);\n }\n\n-static GIT_PATH_FUNC(git_path_bisect_names, \"BISECT_NAMES\")\n-static GIT_PATH_FUNC(git_path_bisect_ancestors_ok, \"BISECT_ANCESTORS_OK\")\n-static GIT_PATH_FUNC(git_path_bisect_run, \"BISECT_RUN\")\n-static GIT_PATH_FUNC(git_path_bisect_start, \"BISECT_START\")\n-static GIT_PATH_FUNC(git_path_bisect_log, \"BISECT_LOG\")\n-static GIT_PATH_FUNC(git_path_bisect_terms, \"BISECT_TERMS\")\n-static GIT_PATH_FUNC(git_path_bisect_first_parent, \"BISECT_FIRST_PARENT\")\n+static GIT_PATH_FUNC(git_path_bisect_names, \"bisect-state/BISECT_NAMES\")\n+static GIT_PATH_FUNC(git_path_bisect_ancestors_ok,\n\"bisect-state/BISECT_ANCESTORS_OK\")\n+static GIT_PATH_FUNC(git_path_bisect_run, \"bisect-state/BISECT_RUN\")\n+static GIT_PATH_FUNC(git_path_bisect_start, \"bisect-state/BISECT_START\")\n+static GIT_PATH_FUNC(git_path_bisect_log, \"bisect-state/BISECT_LOG\")\n+static GIT_PATH_FUNC(git_path_bisect_terms, \"bisect-state/BISECT_TERMS\")\n+static GIT_PATH_FUNC(git_path_bisect_first_parent,\n\"bisect-state/BISECT_FIRST_PARENT\")\n\n\nNote that this is just an example. I will not be removing the existing\npaths instead I will be adding new paths to keep both backward and forward\ncompatibility. I will update all the writes in state files with both the\npaths and all the reads with first a check for bisect_state directory and\nthen read from bisect state directory if it is present else first migrate\nfrom .git directory and then read.\n\n\n***************************************\nChallenges with Backward Compatibility\n***************************************\n\nI plan to implement a migration mechanism that will detect whether the\nlegacy bisect state directory “bisect-state” is present or not during\nevery access for the state file of git bisect. This migration phase will\nautomatically copy the state files (BISECT_*) from “./git” directory to\nthe new “.git/bisect-state” directory, ensuring a seamless transition for\nusers while maintaining the compatibility with existing scripts and tools.\nThe biggest challenge is not to let the existing functionality break.\n\nThinking about the scenario that a user can upgrade while bisecting. I\nthink it won't be enough. So do you think we can add this migration step\nevery time the bisect state files are accessed. Also to address the issue\nof switching back to an older version, we will not delete the older files?\nAnd instead what I am thinking is that we will end up maintaining the\nstate files at two places one in .git directory and other in\n.git/bisect-state.\n\nAs a solution for this I think we can start by managing the BISECT_* files\nat both the places and at a later stage when we deprecate the current\nversion of git we can entirely remove the management of BISECT_* files in\nthe “.git” directory. And we can also provide a backward compatibility\nnote in the release version note for this to let the user know about the\nparticular change.\n\n***********************************************\nStrategies for Handling Backward Compatibility:\n***********************************************\n\nBefore implementing any changes, a good understanding of how git-bisect\nworks and how it is structured is very important. So, I will thoroughly\nanalyze the existing usage patterns of git-bisect and list down all the\npotential areas of impact.\n\nTo validate the codebase changes and ensure the stability and the backward\ncompatibility of git-bisect command. I will write unit tests and\nintegration tests for all the required changes.\n\n   3. I will also try to create some real scenarios where I will be\nmanually testing the desired behavior.\n\n   4. We might also need some regression tests to test some of the\nfunctionality which can't be tested using unit tests. I will be writing\nthese in bash and will be adding it in a new test case file inside the\ngit/t directory or maybe in the \"git\\t\\t6030-bisect-porcelain.sh\" file. I\nwill try mocking a scenario where we have the BISECT_* files available in\nthe .git directory and then run git bisect using the command line and then\ncheck the expected results.\n\n\nHere is a list of a few tests which I am able to think of as of now:\n\n1. Verify correct relocation of state files during initialization.\n2. Test compatibility with existing bisect scripts and tools.\n3. Validate handling of edge cases, such as empty or corrupted stat files,\nto prevent unexpected behavior\n\nI am pretty sure I am still missing some of the problems which I may face\nin the future but I will figure them out too when they arrive.\n\n\n********\nTimeline\n********\n\nI will be starting the project as soon as I receive the confirmation of my\nproposal getting selected for GSoC.\n\n\nHere is a list of phases during the GSoC period for this project. While\nthese are just the approximations, actual timeline may vary because of the\nreview iterations or unpredictable scenarios.\n\n1. Understanding the existing implementation of Bisect command\n- This includes understanding how to test the changes locally which are\nmade in the bisect command efficiently\n- Get more familiar with the style of writing the code\n\n2. Start working on the task to add the directory\n- Updating all the references wherever these bisect files are used\n- Writing/Updating tests to test all the changes made\n\n3. Start with supporting backward compatibility\n- For this phase what I am thinking is of adding a stage just after the\ninitialization of git bisect command which will detect if there exists\nsome files by the name BISECT_* and migrate all those files into the\n“.git/bisect” directory.\n\n4. Adding Tests\n- Through testing for backward compatibility is very very important so\nthat the changes don’t break the existing changes.\n\n\nAvailability\n\nI will be able to contribute 2-3 hours on weekdays and minimum 6 hours on\nweekends. Which gives me around 22-27 hours per week to work on the\nproject. I will work till a minimum span of 14 weeks (can be extended)\nduring the GSoC. I will try my best to keep this time commitment and be\nalways available through the community’s mailing list. Also, I have exams\nin the first week of June so I will have limited availability during that\nperiod. The project might take somewhere around 175-350 hours. I have\ntaken all the factors into factor including my graduation month which is\nJuly 2024 to calculate the timings I will be able to contribute.\n\nAfter GSoC\n\nAfter GSoC I intend to be a part of the community and keep contributing to\nthe git’s codebase. I eagerly want to learn a lot from the git community\nand enhance my skills. I also see myself making important contributions to\ngit in the future.\n\nWhen I first joined the community 2 months ago, the ancient way of\ncollaborating through a mailing list by sending diff patches was really\npuzzling (GitHub was the only means that I knew about for open-source\ncollaboration). After sending a patch I got a little comfortable with it\nand started loving it.\nClosing remarks\n\nI am really enthusiastic to contribute to git. I really want to learn a\nlot from my mentors and the whole git community. Everyone contributes\nusing git, why not contribute to git :).\n\nIn the end I really want to thank the whole community, especially\nChristian and Junio, for their valuable time in reviewing my patches and\nguiding me with the problems I faced.\n\nReferences\n\n[1]  Github Profile - https://github.com/aryangupta701\n[2]  ZAP Project - https://github.com/zaproxy\n[3]  Pull Requests -\nhttps://github.com/search?q=org%3Azaproxy+type%3Apr+sort%3Aupdated-asc++au\nthor%3Aaryangupta701&type=pullrequests\n[4]  GSoC 2023 Project -\nhttps://www.zaproxy.org/blog/2023-09-11-browser-recorder/\n[5]  SoC Ideas - https://git.github.io/SoC-2024-Ideas/\n[6]  Migrate Test Script -\nhttps://lore.kernel.org/git/pull.1675.v2.git.1709243831190.gitgitgadget@gm\nail.com/T/#t\n[7] Migrate Test Script Hash Link:\nhttps://github.com/gitgitgadget/git/commit/06ac51898156b7bba0a42d36731285e\n[8]  Zero Count Optimization-\nhttps://lore.kernel.org/git/20240310162614.62691-2-garyan447@gmail.com/T/#\nu\n[9]  Issue Raised - https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/\n[10]  Git References -\nhttps://git-scm.com/book/en/v2/Git-Internals-Git-References\n[11] Git bisect - https://git-scm.com/docs/git-bisect\n[12]  Reftables - https://git-scm.com/docs/reftable\n\nThanks & Regards,\nAryan\n> Hi,\n>\n> On Sat, Mar 16, 2024 at 7:58 PM Aryan Gupta <garyan447@gmail.com> wrote:\n> >\n> > Hello everyone.\n> >\n> > I hope you are doing well. I am writing this email to get a review for\n> > my GSoC proposal.\n> >\n> > Thanks in advance.\n> >\n> > Regards\n> > Aryan\n> >\n> > Here it goes:\n> >\n> > -- Refactor git-bisect(1) to make its state self-contained --\n> > =============================================================\n> >\n> > -- Personal Info --\n> > ====================\n> >\n> > Full name :     Aryan Gupta\n> > E-mail    :     garyan447@gmail.com\n> > Tel       :     (+91) 7018273899\n> > Education :     Graphic Era University, Dehradun, India\n> > Year      :     Final Year\n> > Major     :     Computer Science and Engineering\n> > GitHub    :     [1]\n> >\n> > -- About Me --\n> > ====================\n> >\n> > I have been enthusiastic about open source from the very beginning of\n> > my journey as a software developer. I’ve contributed to other\n> > open-source projects, though still a beginner, I’m generally familiar\n> > with the process of contribution. The related experiences are all in\n> > the contribution graph on my GitHub profile page [1]. In the ZAP\n> > Project[2] community, I’ve made over 50 PRs [3]. I also participated\n> > in the Google Summer of Code 2023 with the OWASP Foundation and\n> > successfully completed it as well [4]. I have contributed to some\n> > other small projects as well on GitHub.\n>\n> It's interesting to know that you have already participated in a GSoC.\n> Is there a single blog post about this or more?\n>\n> > I came to participate in the Git community this year (around\n> > February). I got myself rather comfortable with the contribution\n> > process by writing, replying, and auditing different sorts of patches\n> > in the community.\n> >\n> > With the patches done so far, I’m getting more familiar with the Git\n> > internals, project structures, commonly used APIs, test suites,\n> > required tech stacks, and coding guidelines. For understanding better\n> > about Git, I read and reread the documentation a few times, including\n> > ‘MyFirstContribution.txt’, ‘MyFirstObjectWalk.txt’, and ‘Hacking Git’.\n> > The book Pro Git also helped me to understand the Git internals\n> > better.\n> >\n> > Effective communication with mentors is a very important part of\n> > Google Summer of Code Program. I know when to ask the right questions\n> > and I do every possible thing I can do before asking any question.\n> > This trait of mine always proved to be very useful and I believe it\n> > will be really beneficial for me for the completion of this GSoC\n> > project as well.\n>\n> Ok.\n>\n> > -- Before GSoC --\n> > ====================\n> >\n> > -- Synopsis --\n> > -----------------------\n> >\n> > I’m picking the project idea “Refactor git-bisect(1) to make its state\n> > self-contained” from the SoC 2024 Ideas page [5]. This idea aims to\n> > make git-bisect(1) self-contained. Its difficulty should be medium,\n> > and the expected project size takes somewhere between 175 hours to 350\n> > hours.\n> >\n> > The git-bisect(1) command is used to find a commit in a range of\n> > commits that introduced a specific bug. Starting a bisection run\n> > creates a set of state files into the Git repository which record\n> > various different parameters like “.git/BISECT_START”. These files\n> > look almost like refs due to their names being all-uppercase. This has\n> > led to confusion with the new “reftable” backend because it wasn’t\n> > quite clear whether those files are in fact refs or not.\n> >\n> > As it turns out they are not refs and should never be treated like\n> > one. Overall, it has been concluded that the way those files are\n> > currently stored is not ideal. Instead of having a proliferation of\n> > files in the Git directory, it was discussed whether the bisect state\n> > should be moved into its own “bisect-state” subdirectory. This would\n> > make it more self-contained and thereby avoid future confusion. It is\n> > also aligned with the sequencer state used by rebases, which is neatly\n> > contained in the “rebase-apply” and “rebase-merge” directories.\n> >\n> > The goal of this project would be to realize this change. While\n> > rearchitecting the layout should be comparatively easy to do, the\n> > harder part will be to hash out how to handle backwards compatibility.\n>\n> It's Ok to copy the project description, or parts of it, from the idea\n> page, but please say that you have done so. This way we can just skip\n> this when we read your proposal.\n>\n> > -- Benefits to Community --\n> > --------------------------------\n> >\n> > By joining the community and working on this idea, I can collaborate\n> > with my mentors and fellow community members to enhance the user\n> > experience for those who use git-bisect(1). Additionally, creating a\n> > clear distinction between the refs and the git-bisect state files\n> > through this project would be highly beneficial for the community.\n> >\n> > -- Why? --\n> > -----------------\n> >\n> > For me, the biggest question is always why I am doing something. So to\n> > answer why I want to contribute to Git in this Google Summer of Code\n> > is the learning I will get while communicating with the mentors and\n> > the git community. I want to learn as much as I could in this phrase.\n> > Also, I want a kick start to begin my journey of contributing to git\n> > for a long term. Why I chose git was mainly because I wanted to\n> > explore something which is being used by almost every software\n> > developer.\n> >\n> > -- Microproject --\n> > ------------------------------\n> >\n> > - Modernize a test script [6]\n> >   - Status: merged into master\n>\n> Please add a link to (or the hash of) the commit that merges your\n> commit(s) into the master branch.\n>\n> >   - Description: Modernize the formatting of the test script to align\n> > with current standards and improve its overall readability.\n> >   - Remarks: This was my first patch in git which helped me to\n> > understand a lot about how the process of submitting a patch and\n> > review works.\n> >\n> > -- Other Patches --\n> > ----------------------------\n> >\n> > Other than the required microproject, I’ve submitted a few other\n> > patches when I stumbled upon potential modifications, these patches\n> > are:\n> >\n> > - Zero Count Optimization [7]\n> >   - Status: Under Review\n>\n> Looking at the thread, it seems to me that it has been reviewed and we\n> are expecting a reroll from you with at least a better commit message.\n>\n> >   - Description: Optimize for efficiency using trailing zeros for set\n> > bit iteration\n> >   - Remarks: This was a great learning task. I learned how tiny things\n> > matter and small optimizations might make a big impact on performance.\n> >\n> >\n> > -- In GSoC --\n> > ====================\n> >\n> > -- Plan --\n> > ----------------\n> >\n> > What is Git Bisect?\n> >\n> > Git Bisect is a git command which helps to find which commit\n> > introduced the bug into the codebase at a faster rate by leveraging\n> > the power of binary search.\n> >\n> >\n> > The project idea is relatively easy to understand by the description\n> > itself. Git bisect stores some state files such as BISECT_START,\n> > BISECT_FIRST_PARENT etc which looks very similar to the naming\n> > convention used for creating the refs file. Due to this similar naming\n> > convention it sometimes causes unexpected results when these state\n> > files are confused as the ref files.\n>\n> I don't think there are unexpected results. I think it's mostly a\n> clarification, standardization and cleanup issue.\n>\n> > In order to fix this problem we can create a new \".git/bisect-state\"\n> > directory and store all the state files which belong to the\n> > git-bisect(1) command in that directory as proposed by Patrick and\n> > store all the files as follows.\n> >\n> >\n> > - BISECT_TERMS -> bisect-state/terms\n> > - BISECT_LOG -> bisect-state/log\n> > - BISECT_START -> bisect-state/start\n> > - BISECT_RUN -> bisect-state/run\n> > - BISECT_FIRST_PARENT -> bisect-state/first-parent\n> > - BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok\n>\n> Yeah, please link to Patrick's email where he suggests this. And\n> please clarify what is quoted verbatim from his email. It is Ok to\n> copy paste from existing emails, but it helps reviewing proposals if\n> you are clear about this as we can then skip those parts.\n>\n> > While the change looks very simple, it actually is. We will just\n> > update all the paths from where these files are being accessed. When I\n> > went through the code of bisect.c file I found that the path is pretty\n> > easy to configure we just need to modify it at a few places. The main\n> > problem is to efficiently handle the backward compatibility and\n> > implement proper test cases to not let the existing things break. I\n> > have already gone through the bisect.c file a couple of times just\n> > reading and trying to understand all the functions and was able to\n> > understand a lot of things about how it works.\n>\n> There is \"bisect.c\" and there is \"builtin/bisect.c\". Please make it\n> clearer which file(s) you are talking about. Also code examples of how\n> you would update things could be useful.\n>\n> > -- Challenges with Backward Compatibility --\n> > --------------------------------------------\n> >\n> > I plan to implement a migration mechanism that will detect whether the\n> > legacy stat file like BISECT_* are present or not during the\n>\n> Maybe: s/stat file/status files/\n>\n> > initialization of git bisect.\n>\n> What do you mean by \"initialization of git bisect\". Does that take\n> into account the fact that users could upgrade while they are\n> bisecting? What if they switch back to an older version after\n> upgrading?\n>\n> Do you plan to always check for any \"BISECT_*\" file or would a check\n> for the \"bisect-state\" first would help?\n>\n> > This migration phase will automatically\n> > move these files to the new “.git/bisect-state” directory, ensuring a\n> > seamless transition for users while maintaining the compatibility with\n> > existing scripts and tools. The biggest challenge is not to let the\n> > existing functionality break.\n> >\n> >\n> > -- Strategies for Handling Backward Compatibility --\n> > ---------------------------------------------------------\n> >\n> > 1. Before implementing any changes, a good understanding of how\n> > git-bisect works and how it is structured is very important. So, I\n> > will thoroughly analyze the existing usage patterns of git-bisect and\n> > list down all the potential areas of impact.\n> >\n> > 2. To validate the codebase changes and ensure the stability and the\n> > backward compatibility of git-bisect command. I will write unit tests\n> > for all the required changes.\n>\n> Do you mean unit tests using the new unit test framework in C. Could\n> you show an example?\n>\n> > 3. I will also try to create some real scenarios where I will be\n> > manually testing the desired behavior.\n> >\n> > 4. We might also need some regression tests to test some of the\n> > functionality which can't be tested using unit tests.\n>\n> In which test script would you add them?\n>\n> > Here is a list of a few tests which I am able to think of as of now:\n> >\n> > 1. Verify correct relocation of state files during initialization.\n> > 2. Test compatibility with existing bisect scripts and tools.\n> > 3. Validate handling of edge cases, such as empty or corrupted state\n> > files, to prevent unexpected behavior\n> >\n> > I am pretty sure I am still missing some of the problems which I may\n> > face in the future but I will figure them out too when they arrive.\n> >\n> > -- Timeline --\n> > ------------------\n> >\n> > I will be starting the project as soon as I receive the confirmation\n> > of my proposal getting selected for GSoC.\n> >\n> > Here is a list of phases during the GSoC period for this project.\n> > While these are just the approximations, the actual timeline may vary\n> > because of the review iterations or unpredictable scenarios.\n> >\n> > 1. Understanding the existing implementation of Bisect command\n> >     - This includes understanding how to test the changes locally\n> > which are made in the bisect command efficiently\n> >     - Get more familiar with the style of writing the code\n> >\n> > 2. Start working on the task to add the directory\n> >     - Updating all the references wherever these bisect files are used\n> >     - Writing/Updating tests to test all the changes made\n> >\n> > 3. Start with supporting backward compatibility\n> >     - For this phase what I am thinking is of adding a stage just\n> > after the initialization of git bisect command which will detect if\n> > there exist some files by the name BISECT_* and migrate all those\n> > files into the “.git/bisect” directory.\n> >\n> > 4. Adding Tests\n> >     - Through testing for backward compatibility is very very\n> > important so that the changes don’t break the existing changes.\n> >\n> > 5. Documenting the changes\n> >     - This might also go side by side if mentors need some weekly\n> > documentation of the tasks done.\n>\n> Tests and documentation should be part of the patches that change the\n> behavior. So it doesn't really make sense to list them separately in\n> the timeline.\n>\n> > -- Availability --\n> > ----------------------\n> >\n> > I will be able to contribute 2-3 hours on weekdays and minimum 6 hours\n> > on weekends. Which gives me around 22-27 hours per week to work on the\n> > project. I will work till a minimum span of 14 weeks (can be extended)\n> > during the GSoC. I will try my best to keep this time commitment and\n> > be always available through the community’s mailing list. Also, I have\n> > exams in the first week of June so I will have limited availability\n> > during that period. The project might take somewhere around 175-350\n> > hours.\n>\n> Thanks for these details related to your availability. As this is your\n> final year, when are you expecting to graduate?\n>\n> > -- After GSoC --\n> > ---------------------\n> >\n> > After GSoC I intend to be a part of the community and keep\n> > contributing to the git’s codebase. I eagerly want to learn a lot from\n> > the git community and enhance my skills. I also see myself making\n> > important contributions to git in the future.\n> >\n> > When I first joined the community 2 months ago, the ancient way of\n> > collaborating through a mailing list by sending diff patches was\n> > really puzzling (GitHub was the only means that I knew about for\n> > open-source collaboration). After sending a patch I got a little\n> > comfortable with it and started loving it.\n> >\n> > -- Closing remarks --\n> > ----------------------------\n> >\n> > I am really enthusiastic to contribute to git. I really want to learn\n> > a lot from my mentors and the whole git community. Everyone\n> > contributes using git, why not contribute to git :).\n> >\n> > In the end I really want to thank the whole community, especially\n> > Christian and Junio, for their valuable time in reviewing my patches\n> > and guiding me with the problems I faced.\n>\n> Thanks for your proposal. Please make sure you submit it soon as a pdf\n> file to the GSoC website. It can then be updated by uploading a new\n> pdf until the April 2 1800 UTC deadline.\n"},{"id":"491565","messageId":"CAP8UFD1U3j4tf3snk0qcDjHPRKxuaUVZOw7GuCEwAnXb-gRvHQ@mail.gmail.com","threadId":"61134","inReplyTo":"CAMbn=B58_KSvkEMEsCnrN6rGL61+qFv9NqcOO8adyU5A37=vjQ@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-03-26T10:29:57Z","receivedAt":"2024-03-26T10:30:11Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Aryan,\n\nOn Thu, Mar 21, 2024 at 2:21 PM Aryan Gupta <garyan447@gmail.com> wrote:\n\n> On Wed, Mar 20, 2024 at 12:06 PM Christian Couder\n> <christian.couder@gmail.com> wrote:\n\n> > On Sat, Mar 16, 2024 at 7:58 PM Aryan Gupta <garyan447@gmail.com> wrote:\n\n> > > -- About Me --\n> > > ====================\n> > >\n> > > I have been enthusiastic about open source from the very beginning of\n> > > my journey as a software developer. I’ve contributed to other\n> > > open-source projects, though still a beginner, I’m generally familiar\n> > > with the process of contribution. The related experiences are all in\n> > > the contribution graph on my GitHub profile page [1]. In the ZAP\n> > > Project[2] community, I’ve made over 50 PRs [3]. I also participated\n> > > in the Google Summer of Code 2023 with the OWASP Foundation and\n> > > successfully completed it as well [4]. I have contributed to some\n> > > other small projects as well on GitHub.\n> >\n> > It's interesting to know that you have already participated in a GSoC.\n> > Is there a single blog post about this or more?\n>\n> Here it is: https://www.zaproxy.org/blog/2023-09-11-browser-recorder/\n\nI saw that there is one blog post, but I wanted to ask if there are\nmore blog posts. That's because we ask GSoC contributors to post on\ntheir blog at least every 2 weeks and if possible every week.\n\n> > > -- Strategies for Handling Backward Compatibility --\n> > > ---------------------------------------------------------\n> > >\n> > > 1. Before implementing any changes, a good understanding of how\n> > > git-bisect works and how it is structured is very important. So, I\n> > > will thoroughly analyze the existing usage patterns of git-bisect and\n> > > list down all the potential areas of impact.\n> > >\n> > > 2. To validate the codebase changes and ensure the stability and the\n> > > backward compatibility of git-bisect command. I will write unit tests\n> > > for all the required changes.\n> >\n> > Do you mean unit tests using the new unit test framework in C. Could\n> > you show an example?\n> >\n>\n> Not sure about what is the standard way that git uses for writing unit tests.\n> Could you tell me a bit about this?\n\nI was just asking if you planned to use the new unit test framework in\nC. The \"Move existing tests to a unit testing framework\" project that\nwe propose on https://git.github.io/SoC-2024-Ideas/ is about moving\nsome unit tests to this new unit test framework. Please take a look at\nthat project to get more information about this subject.\n\n> > > 3. I will also try to create some real scenarios where I will be\n> > > manually testing the desired behavior.\n> > >\n> > > 4. We might also need some regression tests to test some of the\n> > > functionality which can't be tested using unit tests.\n> >\n> > In which test script would you add them?\n>\n> I will be writing these in bash and will be adding it in a new test case file\n> inside the git/t directory or maybe in \"git\\t\\t6030-bisect-porcelain.sh\"\n\nIt's better to always use the Unix notation for paths like\n\"t/t6030-bisect-porcelain.sh\" starting at the root of the repo, rather\nthan mixing the Unix and Windows notations and adding \"git/\" before\nthe root.\n\n> file. I will try mocking a scenario where we have the BISECT_* files available\n> in the .git directory and then run git bisect using the command line and then\n> check the expected results.\n\nThe t/*.sh test scripts are the right place for end-to-end tests\n(sometimes called \"black box\" tests), but not for unit tests that\nwould test some C functions. Both unit tests and end-to-end tests\ncould be regression tests or performance tests.\n\n> > > 4. Adding Tests\n> > >     - Through testing for backward compatibility is very very\n> > > important so that the changes don’t break the existing changes.\n> > >\n> > > 5. Documenting the changes\n> > >     - This might also go side by side if mentors need some weekly\n> > > documentation of the tasks done.\n> >\n> > Tests and documentation should be part of the patches that change the\n> > behavior. So it doesn't really make sense to list them separately in\n> > the timeline.\n>\n> Okay. Maybe a blog post could be a part of this?\n\nWe ask GSoC contributors to post weekly on their blog, so except for a\nfinal blog post, most of the blogging should be also part of the\nregular work.\n\nThanks for updating your proposal.\n"},{"id":"491623","messageId":"CAMbn=B6vARzcqkqFRHDhZ2NJoBRyaUCCUcvqd=3pFk92T-gjWA@mail.gmail.com","threadId":"61134","inReplyTo":"CAP8UFD1U3j4tf3snk0qcDjHPRKxuaUVZOw7GuCEwAnXb-gRvHQ@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained","fromName":"Aryan Gupta","fromEmail":"garyan447@gmail.com","sentAt":"2024-03-27T00:23:14Z","receivedAt":"2024-03-27T00:23:27Z","isPatch":false,"sender":{"key":"garyan447@gmail.com","avatar":"https://avatars.githubusercontent.com/u/87857234?v=4"},"body":"Hey Christian\n\nThank you for the response.\n\nOn Tue, Mar 26, 2024 at 11:30 AM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi Aryan,\n>\n> On Thu, Mar 21, 2024 at 2:21 PM Aryan Gupta <garyan447@gmail.com> wrote:\n>\n> > On Wed, Mar 20, 2024 at 12:06 PM Christian Couder\n> > <christian.couder@gmail.com> wrote:\n>\n> > > On Sat, Mar 16, 2024 at 7:58 PM Aryan Gupta <garyan447@gmail.com> wrote:\n>\n> > > > -- About Me --\n> > > > ====================\n> > > >\n> > > > I have been enthusiastic about open source from the very beginning of\n> > > > my journey as a software developer. I’ve contributed to other\n> > > > open-source projects, though still a beginner, I’m generally familiar\n> > > > with the process of contribution. The related experiences are all in\n> > > > the contribution graph on my GitHub profile page [1]. In the ZAP\n> > > > Project[2] community, I’ve made over 50 PRs [3]. I also participated\n> > > > in the Google Summer of Code 2023 with the OWASP Foundation and\n> > > > successfully completed it as well [4]. I have contributed to some\n> > > > other small projects as well on GitHub.\n> > >\n> > > It's interesting to know that you have already participated in a GSoC.\n> > > Is there a single blog post about this or more?\n> >\n> > Here it is: https://www.zaproxy.org/blog/2023-09-11-browser-recorder/\n>\n> I saw that there is one blog post, but I wanted to ask if there are\n> more blog posts. That's because we ask GSoC contributors to post on\n> their blog at least every 2 weeks and if possible every week.\n>\nOh okay. No, the org didn't have any such criteria we usually had\na google meeting once a week where we discussed everything\nabout the week's progress and the next week's plan. Yes I can\nsurely write a blog every one or two weeks whichever would be\ncomfortable for sure if I contribute to git.\n\n> > > > -- Strategies for Handling Backward Compatibility --\n> > > > ---------------------------------------------------------\n> > > >\n> > > > 1. Before implementing any changes, a good understanding of how\n> > > > git-bisect works and how it is structured is very important. So, I\n> > > > will thoroughly analyze the existing usage patterns of git-bisect and\n> > > > list down all the potential areas of impact.\n> > > >\n> > > > 2. To validate the codebase changes and ensure the stability and the\n> > > > backward compatibility of git-bisect command. I will write unit tests\n> > > > for all the required changes.\n> > >\n> > > Do you mean unit tests using the new unit test framework in C. Could\n> > > you show an example?\n> > >\n> >\n> > Not sure about what is the standard way that git uses for writing unit tests.\n> > Could you tell me a bit about this?\n>\n> I was just asking if you planned to use the new unit test framework in\n> C. The \"Move existing tests to a unit testing framework\" project that\n> we propose on https://git.github.io/SoC-2024-Ideas/ is about moving\n> some unit tests to this new unit test framework. Please take a look at\n> that project to get more information about this subject.\n>\nGot it. I read and researched on this and yes I can use the latest unit\ntest framework for writing the unit tests. Also I was thinking of a backup\nplan. If the community later (after getting the proposal accepted) do not\nagree with the project idea. I can work on the migration of these tests as\nwell. Since there are so many tests, I think I can work on a few if this\nhappens. Here is an example:\n\n#include \"test-lib.h\"\n#include \"bisect.h\"\n\nstatic void test_backward_compatibility(void) {\n/*\n* will try to do some bisect operations by\n* keeping the new way of storing bisect state\n* files, not sure about the how the code will\n* look like for now because I haven't gone\n* through git-bisect much but I will do it\n* for sure\n*/\n}\n\n\nint cmd_main(int argc, const char **argv) {\nTEST(test_backward_compatibility(), \"Test backward compatibility of\ngit-bisect\");\n\nreturn test_done();\n}\n\n\n> > > > 3. I will also try to create some real scenarios where I will be\n> > > > manually testing the desired behavior.\n> > > >\n> > > > 4. We might also need some regression tests to test some of the\n> > > > functionality which can't be tested using unit tests.\n> > >\n> > > In which test script would you add them?\n> >\n> > I will be writing these in bash and will be adding it in a new test case file\n> > inside the git/t directory or maybe in \"git\\t\\t6030-bisect-porcelain.sh\"\n>\n> It's better to always use the Unix notation for paths like\n> \"t/t6030-bisect-porcelain.sh\" starting at the root of the repo, rather\n> than mixing the Unix and Windows notations and adding \"git/\" before\n> the root.\n\nOkay.\n\n>\n> > file. I will try mocking a scenario where we have the BISECT_* files available\n> > in the .git directory and then run git bisect using the command line and then\n> > check the expected results.\n>\n> The t/*.sh test scripts are the right place for end-to-end tests\n> (sometimes called \"black box\" tests), but not for unit tests that\n> would test some C functions. Both unit tests and end-to-end tests\n> could be regression tests or performance tests.\n>\nOkay\n\n> > > > 4. Adding Tests\n> > > >     - Through testing for backward compatibility is very very\n> > > > important so that the changes don’t break the existing changes.\n> > > >\n> > > > 5. Documenting the changes\n> > > >     - This might also go side by side if mentors need some weekly\n> > > > documentation of the tasks done.\n> > >\n> > > Tests and documentation should be part of the patches that change the\n> > > behavior. So it doesn't really make sense to list them separately in\n> > > the timeline.\n> >\n> > Okay. Maybe a blog post could be a part of this?\n>\n> We ask GSoC contributors to post weekly on their blog, so except for a\n> final blog post, most of the blogging should be also part of the\n> regular work.\n\nOkay.\n\n>\n> Thanks for updating your proposal.\n\n\nThank you\nRegards\n\nAryan Gupta\n"}]}