{"thread":{"id":"61177","subject":"[RFC][GSoC] Proposal: Refactor git-bisect(1)","startedAt":"2024-03-22T10:27:00Z","lastAt":"2024-03-29T09:05:46Z","messageCount":6,"participants":["eugenio gigante","Patrick Steinhardt","Kaartic Sivaraam"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"491229","messageId":"CAFJh0PS_VB8yv7B1uM5+Ts9PtMFtU5mL4y8UUDORKQcYHSoxPA@mail.gmail.com","threadId":"61177","inReplyTo":null,"subject":"[RFC][GSoC] Proposal: Refactor git-bisect(1)","fromName":"eugenio gigante","fromEmail":"giganteeugenio2@gmail.com","sentAt":"2024-03-22T10:26:48Z","receivedAt":"2024-03-22T10:27:00Z","isPatch":false,"sender":{"key":"giganteeugenio2@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116371051?v=4"},"body":"Hi all, this is my proposal for the GSoC 2024.\n\n----------------------------------------------------------------------------------------------------\n\nRefactor git-bisect(1) to make its state self-contained\n\nContacts\n-------------------\n\nFull Name: Eugenio Gigante\nEmail: giganteeugenio2@gmail.com\nGithub: www.github.com/EuGig\n\n\nSynopsis\n------------\n\nThe git-bisect(1) tool is employed to pinpoint the exact commit within a\nseries of commits that introduced a particular bug. When initiating a\nbisection session,\nit generates a collection of state files within the Git repository,\ndocumenting diverse\nparameters such as \".git/BISECT_START\". Instead of having different\nfiles scattered\nin the ‘.git’ directory, it has been suggested by Patrick to introduce\na new ‘.git/bisect-state’\ndirectory which will contain the state files\n(https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/).\nThe aim of the project is to implement this new layout for storing\ngit-bisect(1) related files.\nThe project will also handle backward compatibility issues that may\narise with such a change.\nThis is one of the project ideas suggested by the community of Git.\nThe difficulty for the project should be medium and it should take\nsomewhat between 175 to 350 hours.\n\n\nContributions\n-------------------\n\nadd.c: use unsigned integral type for collection of bits\n(https://lore.kernel.org/git/20240224112638.72257-2-giganteeugenio2@gmail.com/)\n\n\nDescription:\n\nSince the MSB of signed integral type’ is special, ‘flags’ fields should be\ndeclared of type ‘unsigned integral’. builtin/add.c:refresh() declares\n'flags' as signed,\nand uses it  to call refresh_index() that expects an unsigned value.\nFix this by modifying its type ‘unsigned int’.\n\nAlthough the code was easy, this patch gave me the opportunity to get\nfamiliar with\nthe process of submitting patches. The lesson learned was not only\nabout understanding\ngit commands for formatting and sending patches to the mailing list;\nbut, most importantly,\nwas about how to interact with the community; i. e., how to interact\nwith reviewers,\nto ask them questions and give them answers. That is why I chose a\nmicro-project idea\nthat explicitly required interaction with the community, before\nwriting any code.\n\nStatus:\n\nMerged to master on: Thu Mar 7 15:59:41 2024\ncommit f46a3f143eba661b9eb2b1e741447d6709eb6e90\n\n\nDeliverables\n------------------\n\nAs soon as the acceptance to the program is communicated, I will start writing a\nsort of Backlog of required changes which has to be shared with mentors.\nThis has the goal of better tracking progress and possible issues.\nAlready individuated changes and possible strategies are considered in\nwhat follows:\n\n1. First, one needs to inspect the possible impacts such a change could have\nregarding Backward compatibility. There will be two possible situations in which\nbackward compatibility breaks:\n\na. (Noted by Junio (https://lore.kernel.org/git/xmqqwms0ndvu.fsf@gitster.g/)).\nPeople switch versions in the middle of a git-bisect session. Even\nthough I think this\ncase would not be that common, one should take this into consideration\nnonetheless.\n\nb. (Noted by Patrick (https://lore.kernel.org/git/ZbDPqOnyLw4yhu--@tanuki/)).\nDifferent implementations of Git could suffer backward\nincompatibilities like Libgit2,\nJGit and Dulwich. In this case, I will investigate if (and how) these\ntools would suffer the change.\n\nIn this phase it is important to find an agreement with the community\nif the refactoring\nwould be worth it, and in case it is, to find the best solution to\nguarantee backward compatibility.\nThe simplest way seems to be to teach Git how to recognise the old\nstyle layout and move\nthe files by following the new one. This can be achieved by checking\nthe presence of state files\ninside ‘.git’, just after the starting of a bisect session and by\nmoving them accordingly.\n\n\n2. After a strategy for backward compatibility is decided, I will\nrefactor the directory\nwhere all the file states are created. This is done by changing the\nfunction factory\n‘GIT_PATH_FUNC’ in ‘builtin/bisect.c‘’. The following is an example\nfor ‘BISECT_START’:\n\n- #static GIT_PATH_FUNC(git_path_bisect_start, “BISECT_START”)\n+ #static GIT_PATH_FUNC(git_path_bisect_start, “bisect-state/start”)\n\nSimilarly for ‘bisect-state/terms’, etc. This kind of changes should\nalso be done in ‘bisect.c’\n(which contains the binary searching algorithm git-bisect(1) uses).\nThen, as noted by\nJunio (https://lore.kernel.org/git/xmqqwms0ndvu.fsf@gitster.g/) this\npath should be\nmarked per-worktree, since each worktree can have its own bisect sessions.\nProbably, also files related to git-worktree use the directory of\nstate files somehow,\nso one should also check them.\n\n3. Write some tests for the new layout. The plan is to use the new\nunit testing framework. First tests that come to mind are:\n\na. Check that the state files are inside ‘.git/bisect-state’.\nb. Check if the path pertains to GIT_DIR and not COMMON_DIR.\nc. Check that after adding a worktree which was being bisected does\nnot somehow spoil the session and the state files.\n\nThis can be taken as an example of test file for git-bisect(1) using\nthe new framework:\n\n#include test-lib.h\n#include bisect.h\n\n// Write functions like:\n// t_bisect_dir_init()\n// t_worktree_init()\n// t_test_layout()\n// and include them in cmd_main\n\nint cmd_main(int argc, const char **argv)\n{\nif (!TEST(t_bisect_dir_init(), “bisect directory initialized”))\ntest_skip_all(“Bisect initialization failed”);\nif (!TEST(t_worktree_init(), “worktree initialized”))\ntest_skip_all(“Worktree initialization failed”);\nTEST(t_layout(), “new laypout”);\n\nreturn test_done();\n}\n\n4. Implement strategy for backward compatibility and related tests such as:\n\na. Check if Git correctly recognizes the old layout and in case\ncorrectly moves the files according to the new one.\n\n\nTimeline\n------------\n\nMay 1 - 26:\nCommunity bounding Period.\nRead Documentation.\nWrite Backlog.\n\n\nMay 27 - July 8:\nImplement a new layout for state files.\nWrite tests.\n\nJuly 12 - August 19:\nAssess and implement backward compatibility.\n\nAugust 19 - Deadline :\nWrite documentation for the project.\n\nI can dedicate 3 hours a day during weekdays, and 5 hours during the weekends.\n\n\nBenefits to the Community\n-------------------------------------\n\nHow state files dedicated for git-bisect(1) are stored is not ideal.\nHaving a single directory dedicated to these files, instead of having different\nfiles spread in the Git directory during the bisecting session, is\nbetter and facilitates\neven the removal of them after bisecting.  Moreover, as noted by\nPhillip (https://lore.kernel.org/git/9c800cd5-8d20-4df7-8834-f74ab000695e@gmail.com/#t),\nby aligning the organization of these files to that used for am,\nrebase, cherry-pick, etc.,\nthe repo will have a more coherent and uniform layout.\nThis will enhance readability and maintainability in general.\n\nKarthik [1] also expressed  the need of such refactoring as a prerequisite\nto introduce new syntax checks for pseudoref in ‘is_pseudoref_syntax()’.\n\n\n[1] See Karthik’s commit: 1eba2240f8ba9f05a47d488bb62041c42c5d4b9c\n\n\nBiographical information\n----------------------------------\n\nI’m a former student of Logic and Philosophy who turned to coding\nafter graduating.\nI have been working as a Developer for NTT Data Italia for a year.\nI hold a full-time job, but I've seen that it doesn't conflict with\nthe rules of GSoC\nsince I'm an open source beginner. I am fully capable of managing my\nworkload independently,\nincluding my working hours. I know it is not ideal, but I can\ndefinitely work around\nmy schedule and dedicate time to the project.\n\nBefore, I have contributed small patches to two open source projects:\n- Pydata/Sparse: https://github.com/pydata/sparse/pull/611\n- Pennylane: https://github.com/PennyLaneAI/pennylane/pull/3959\n\n-------------------------------------------------------------------------------------------------\n\nThanks,\nEugenio.\n"},{"id":"491401","messageId":"ZgE1fxIFFQIdtIyN@tanuki","threadId":"61177","inReplyTo":"CAFJh0PS_VB8yv7B1uM5+Ts9PtMFtU5mL4y8UUDORKQcYHSoxPA@mail.gmail.com","subject":"Re: [RFC][GSoC] Proposal: Refactor git-bisect(1)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-25T08:27:43Z","receivedAt":"2024-03-25T08:27:49Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Mar 22, 2024 at 11:26:48AM +0100, eugenio gigante wrote:\n> Hi all, this is my proposal for the GSoC 2024.\n> \n> ----------------------------------------------------------------------------------------------------\n> \n> Refactor git-bisect(1) to make its state self-contained\n> \n> Contacts\n> -------------------\n> \n> Full Name: Eugenio Gigante\n> Email: giganteeugenio2@gmail.com\n> Github: www.github.com/EuGig\n> \n> \n> Synopsis\n> ------------\n> \n> The git-bisect(1) tool is employed to pinpoint the exact commit within a\n> series of commits that introduced a particular bug. When initiating a\n> bisection session,\n> it generates a collection of state files within the Git repository,\n> documenting diverse\n> parameters such as \".git/BISECT_START\". Instead of having different\n> files scattered\n> in the ‘.git’ directory, it has been suggested by Patrick to introduce\n> a new ‘.git/bisect-state’\n> directory which will contain the state files\n> (https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/).\n> The aim of the project is to implement this new layout for storing\n> git-bisect(1) related files.\n> The project will also handle backward compatibility issues that may\n> arise with such a change.\n> This is one of the project ideas suggested by the community of Git.\n> The difficulty for the project should be medium and it should take\n> somewhat between 175 to 350 hours.\n> \n> \n> Contributions\n> -------------------\n> \n> add.c: use unsigned integral type for collection of bits\n> (https://lore.kernel.org/git/20240224112638.72257-2-giganteeugenio2@gmail.com/)\n> \n> \n> Description:\n> \n> Since the MSB of signed integral type’ is special, ‘flags’ fields should be\n> declared of type ‘unsigned integral’. builtin/add.c:refresh() declares\n> 'flags' as signed,\n> and uses it  to call refresh_index() that expects an unsigned value.\n> Fix this by modifying its type ‘unsigned int’.\n> \n> Although the code was easy, this patch gave me the opportunity to get\n> familiar with\n> the process of submitting patches. The lesson learned was not only\n> about understanding\n> git commands for formatting and sending patches to the mailing list;\n> but, most importantly,\n> was about how to interact with the community; i. e., how to interact\n> with reviewers,\n> to ask them questions and give them answers. That is why I chose a\n> micro-project idea\n> that explicitly required interaction with the community, before\n> writing any code.\n> \n> Status:\n> \n> Merged to master on: Thu Mar 7 15:59:41 2024\n> commit f46a3f143eba661b9eb2b1e741447d6709eb6e90\n> \n> \n> Deliverables\n> ------------------\n> \n> As soon as the acceptance to the program is communicated, I will start writing a\n> sort of Backlog of required changes which has to be shared with mentors.\n> This has the goal of better tracking progress and possible issues.\n> Already individuated changes and possible strategies are considered in\n> what follows:\n> \n> 1. First, one needs to inspect the possible impacts such a change could have\n> regarding Backward compatibility. There will be two possible situations in which\n> backward compatibility breaks:\n> \n> a. (Noted by Junio (https://lore.kernel.org/git/xmqqwms0ndvu.fsf@gitster.g/)).\n> People switch versions in the middle of a git-bisect session. Even\n> though I think this\n> case would not be that common, one should take this into consideration\n> nonetheless.\n> \n> b. (Noted by Patrick (https://lore.kernel.org/git/ZbDPqOnyLw4yhu--@tanuki/)).\n> Different implementations of Git could suffer backward\n> incompatibilities like Libgit2,\n> JGit and Dulwich. In this case, I will investigate if (and how) these\n> tools would suffer the change.\n> \n> In this phase it is important to find an agreement with the community\n> if the refactoring\n> would be worth it, and in case it is, to find the best solution to\n> guarantee backward compatibility.\n> The simplest way seems to be to teach Git how to recognise the old\n> style layout and move\n> the files by following the new one. This can be achieved by checking\n> the presence of state files\n> inside ‘.git’, just after the starting of a bisect session and by\n> moving them accordingly.\n\nTo further stress the point: the biggest challenge of this project is\nindeed to find an agreement with the community whether this refactoring\nwill ultimately be worth it. This will require some good arguing on your\npart why exactly you think this is fine and how exactly this will\ninteract with other implementations of Git like libgit2/JGit/Dulwich. It\nmay very well happen that ultimately the community decides that this\nwhole endeavour is not worth it.\n\n> 2. After a strategy for backward compatibility is decided, I will\n> refactor the directory\n> where all the file states are created. This is done by changing the\n> function factory\n> ‘GIT_PATH_FUNC’ in ‘builtin/bisect.c‘’. The following is an example\n> for ‘BISECT_START’:\n> \n> - #static GIT_PATH_FUNC(git_path_bisect_start, “BISECT_START”)\n> + #static GIT_PATH_FUNC(git_path_bisect_start, “bisect-state/start”)\n> \n> Similarly for ‘bisect-state/terms’, etc. This kind of changes should\n> also be done in ‘bisect.c’\n> (which contains the binary searching algorithm git-bisect(1) uses).\n> Then, as noted by\n> Junio (https://lore.kernel.org/git/xmqqwms0ndvu.fsf@gitster.g/) this\n> path should be\n> marked per-worktree, since each worktree can have its own bisect sessions.\n> Probably, also files related to git-worktree use the directory of\n> state files somehow,\n> so one should also check them.\n> \n> 3. Write some tests for the new layout. The plan is to use the new\n> unit testing framework. First tests that come to mind are:\n> \n> a. Check that the state files are inside ‘.git/bisect-state’.\n> b. Check if the path pertains to GIT_DIR and not COMMON_DIR.\n> c. Check that after adding a worktree which was being bisected does\n> not somehow spoil the session and the state files.\n> \n> This can be taken as an example of test file for git-bisect(1) using\n> the new framework:\n> \n> #include test-lib.h\n> #include bisect.h\n> \n> // Write functions like:\n> // t_bisect_dir_init()\n> // t_worktree_init()\n> // t_test_layout()\n> // and include them in cmd_main\n> \n> int cmd_main(int argc, const char **argv)\n> {\n> if (!TEST(t_bisect_dir_init(), “bisect directory initialized”))\n> test_skip_all(“Bisect initialization failed”);\n> if (!TEST(t_worktree_init(), “worktree initialized”))\n> test_skip_all(“Worktree initialization failed”);\n> TEST(t_layout(), “new laypout”);\n> \n> return test_done();\n> }\n\nI don't think that the unit testing framework would be a good fit. The\nintent of that new framework is mostly to test low-level functionality\nthat otherwise cannot be easily tested. But here it should actually be\nquite easy to test things as part of our regular integration-style tests\nin \"t/t*.sh\", so it would be preferable to write those instead.\n\n> 4. Implement strategy for backward compatibility and related tests such as:\n> \n> a. Check if Git correctly recognizes the old layout and in case\n> correctly moves the files according to the new one.\n> \n> \n> Timeline\n> ------------\n> \n> May 1 - 26:\n> Community bounding Period.\n> Read Documentation.\n> Write Backlog.\n> \n> \n> May 27 - July 8:\n> Implement a new layout for state files.\n> Write tests.\n> \n> July 12 - August 19:\n> Assess and implement backward compatibility.\n> \n> August 19 - Deadline :\n> Write documentation for the project.\n> \n> I can dedicate 3 hours a day during weekdays, and 5 hours during the weekends.\n> \n> \n> Benefits to the Community\n> -------------------------------------\n> \n> How state files dedicated for git-bisect(1) are stored is not ideal.\n> Having a single directory dedicated to these files, instead of having different\n> files spread in the Git directory during the bisecting session, is\n> better and facilitates\n> even the removal of them after bisecting.  Moreover, as noted by\n> Phillip (https://lore.kernel.org/git/9c800cd5-8d20-4df7-8834-f74ab000695e@gmail.com/#t),\n> by aligning the organization of these files to that used for am,\n> rebase, cherry-pick, etc.,\n> the repo will have a more coherent and uniform layout.\n> This will enhance readability and maintainability in general.\n> \n> Karthik [1] also expressed  the need of such refactoring as a prerequisite\n> to introduce new syntax checks for pseudoref in ‘is_pseudoref_syntax()’.\n> \n> \n> [1] See Karthik’s commit: 1eba2240f8ba9f05a47d488bb62041c42c5d4b9c\n\nNicely summarized.\n\n> \n> Biographical information\n> ----------------------------------\n> \n> I’m a former student of Logic and Philosophy who turned to coding\n> after graduating.\n> I have been working as a Developer for NTT Data Italia for a year.\n> I hold a full-time job, but I've seen that it doesn't conflict with\n> the rules of GSoC\n> since I'm an open source beginner. I am fully capable of managing my\n> workload independently,\n> including my working hours. I know it is not ideal, but I can\n> definitely work around\n> my schedule and dedicate time to the project.\n> \n> Before, I have contributed small patches to two open source projects:\n> - Pydata/Sparse: https://github.com/pydata/sparse/pull/611\n> - Pennylane: https://github.com/PennyLaneAI/pennylane/pull/3959\n\nThanks for your proposal. Please make sure you submit it as a PDF file\nto the GSoC website soonish, unless you already did that.\n\nPatrick\n"},{"id":"491443","messageId":"CAFJh0PTxhDSW1qsnVRrDxmMnp5k16nPGe6RAgrmWow0rgYV+dw@mail.gmail.com","threadId":"61177","inReplyTo":"ZgE1fxIFFQIdtIyN@tanuki","subject":"Re: [RFC][GSoC] Proposal: Refactor git-bisect(1)","fromName":"eugenio gigante","fromEmail":"giganteeugenio2@gmail.com","sentAt":"2024-03-25T11:00:58Z","receivedAt":"2024-03-25T11:01:10Z","isPatch":false,"sender":{"key":"giganteeugenio2@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116371051?v=4"},"body":"> To further stress the point: the biggest challenge of this project is\n> indeed to find an agreement with the community whether this refactoring\n> will ultimately be worth it. This will require some good arguing on your\n> part why exactly you think this is fine and how exactly this will\n> interact with other implementations of Git like libgit2/JGit/Dulwich. It\n> may very well happen that ultimately the community decides that this\n> whole endeavour is not worth it.\n\nYeah, I'll try to expand a bit in this direction. Meanwhile, if you think\nthere are others tools to look into, besides the already cited\n(libgit2/JGit/Dulwich),\nlike UI interfaces or something else, please let me know.\n(Maybe GitLab is something to keep in mind?)\n\n> I don't think that the unit testing framework would be a good fit. The\n> intent of that new framework is mostly to test low-level functionality\n> that otherwise cannot be easily tested. But here it should actually be\n> quite easy to test things as part of our regular integration-style tests\n> in \"t/t*.sh\", so it would be preferable to write those instead.\n\nOh ok, I thought the testing framework should have been used for all tests.\nI'll change that.\n\n> Thanks for your proposal. Please make sure you submit it as a PDF file\n> to the GSoC website soonish, unless you already did that.\n\nThanks for the review!\n\nIl giorno lun 25 mar 2024 alle ore 09:27 Patrick Steinhardt\n<ps@pks.im> ha scritto:\n>\n> On Fri, Mar 22, 2024 at 11:26:48AM +0100, eugenio gigante wrote:\n> > Hi all, this is my proposal for the GSoC 2024.\n> >\n> > ----------------------------------------------------------------------------------------------------\n> >\n> > Refactor git-bisect(1) to make its state self-contained\n> >\n> > Contacts\n> > -------------------\n> >\n> > Full Name: Eugenio Gigante\n> > Email: giganteeugenio2@gmail.com\n> > Github: www.github.com/EuGig\n> >\n> >\n> > Synopsis\n> > ------------\n> >\n> > The git-bisect(1) tool is employed to pinpoint the exact commit within a\n> > series of commits that introduced a particular bug. When initiating a\n> > bisection session,\n> > it generates a collection of state files within the Git repository,\n> > documenting diverse\n> > parameters such as \".git/BISECT_START\". Instead of having different\n> > files scattered\n> > in the ‘.git’ directory, it has been suggested by Patrick to introduce\n> > a new ‘.git/bisect-state’\n> > directory which will contain the state files\n> > (https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/).\n> > The aim of the project is to implement this new layout for storing\n> > git-bisect(1) related files.\n> > The project will also handle backward compatibility issues that may\n> > arise with such a change.\n> > This is one of the project ideas suggested by the community of Git.\n> > The difficulty for the project should be medium and it should take\n> > somewhat between 175 to 350 hours.\n> >\n> >\n> > Contributions\n> > -------------------\n> >\n> > add.c: use unsigned integral type for collection of bits\n> > (https://lore.kernel.org/git/20240224112638.72257-2-giganteeugenio2@gmail.com/)\n> >\n> >\n> > Description:\n> >\n> > Since the MSB of signed integral type’ is special, ‘flags’ fields should be\n> > declared of type ‘unsigned integral’. builtin/add.c:refresh() declares\n> > 'flags' as signed,\n> > and uses it  to call refresh_index() that expects an unsigned value.\n> > Fix this by modifying its type ‘unsigned int’.\n> >\n> > Although the code was easy, this patch gave me the opportunity to get\n> > familiar with\n> > the process of submitting patches. The lesson learned was not only\n> > about understanding\n> > git commands for formatting and sending patches to the mailing list;\n> > but, most importantly,\n> > was about how to interact with the community; i. e., how to interact\n> > with reviewers,\n> > to ask them questions and give them answers. That is why I chose a\n> > micro-project idea\n> > that explicitly required interaction with the community, before\n> > writing any code.\n> >\n> > Status:\n> >\n> > Merged to master on: Thu Mar 7 15:59:41 2024\n> > commit f46a3f143eba661b9eb2b1e741447d6709eb6e90\n> >\n> >\n> > Deliverables\n> > ------------------\n> >\n> > As soon as the acceptance to the program is communicated, I will start writing a\n> > sort of Backlog of required changes which has to be shared with mentors.\n> > This has the goal of better tracking progress and possible issues.\n> > Already individuated changes and possible strategies are considered in\n> > what follows:\n> >\n> > 1. First, one needs to inspect the possible impacts such a change could have\n> > regarding Backward compatibility. There will be two possible situations in which\n> > backward compatibility breaks:\n> >\n> > a. (Noted by Junio (https://lore.kernel.org/git/xmqqwms0ndvu.fsf@gitster.g/)).\n> > People switch versions in the middle of a git-bisect session. Even\n> > though I think this\n> > case would not be that common, one should take this into consideration\n> > nonetheless.\n> >\n> > b. (Noted by Patrick (https://lore.kernel.org/git/ZbDPqOnyLw4yhu--@tanuki/)).\n> > Different implementations of Git could suffer backward\n> > incompatibilities like Libgit2,\n> > JGit and Dulwich. In this case, I will investigate if (and how) these\n> > tools would suffer the change.\n> >\n> > In this phase it is important to find an agreement with the community\n> > if the refactoring\n> > would be worth it, and in case it is, to find the best solution to\n> > guarantee backward compatibility.\n> > The simplest way seems to be to teach Git how to recognise the old\n> > style layout and move\n> > the files by following the new one. This can be achieved by checking\n> > the presence of state files\n> > inside ‘.git’, just after the starting of a bisect session and by\n> > moving them accordingly.\n>\n> To further stress the point: the biggest challenge of this project is\n> indeed to find an agreement with the community whether this refactoring\n> will ultimately be worth it. This will require some good arguing on your\n> part why exactly you think this is fine and how exactly this will\n> interact with other implementations of Git like libgit2/JGit/Dulwich. It\n> may very well happen that ultimately the community decides that this\n> whole endeavour is not worth it.\n>\n> > 2. After a strategy for backward compatibility is decided, I will\n> > refactor the directory\n> > where all the file states are created. This is done by changing the\n> > function factory\n> > ‘GIT_PATH_FUNC’ in ‘builtin/bisect.c‘’. The following is an example\n> > for ‘BISECT_START’:\n> >\n> > - #static GIT_PATH_FUNC(git_path_bisect_start, “BISECT_START”)\n> > + #static GIT_PATH_FUNC(git_path_bisect_start, “bisect-state/start”)\n> >\n> > Similarly for ‘bisect-state/terms’, etc. This kind of changes should\n> > also be done in ‘bisect.c’\n> > (which contains the binary searching algorithm git-bisect(1) uses).\n> > Then, as noted by\n> > Junio (https://lore.kernel.org/git/xmqqwms0ndvu.fsf@gitster.g/) this\n> > path should be\n> > marked per-worktree, since each worktree can have its own bisect sessions.\n> > Probably, also files related to git-worktree use the directory of\n> > state files somehow,\n> > so one should also check them.\n> >\n> > 3. Write some tests for the new layout. The plan is to use the new\n> > unit testing framework. First tests that come to mind are:\n> >\n> > a. Check that the state files are inside ‘.git/bisect-state’.\n> > b. Check if the path pertains to GIT_DIR and not COMMON_DIR.\n> > c. Check that after adding a worktree which was being bisected does\n> > not somehow spoil the session and the state files.\n> >\n> > This can be taken as an example of test file for git-bisect(1) using\n> > the new framework:\n> >\n> > #include test-lib.h\n> > #include bisect.h\n> >\n> > // Write functions like:\n> > // t_bisect_dir_init()\n> > // t_worktree_init()\n> > // t_test_layout()\n> > // and include them in cmd_main\n> >\n> > int cmd_main(int argc, const char **argv)\n> > {\n> > if (!TEST(t_bisect_dir_init(), “bisect directory initialized”))\n> > test_skip_all(“Bisect initialization failed”);\n> > if (!TEST(t_worktree_init(), “worktree initialized”))\n> > test_skip_all(“Worktree initialization failed”);\n> > TEST(t_layout(), “new laypout”);\n> >\n> > return test_done();\n> > }\n>\n> I don't think that the unit testing framework would be a good fit. The\n> intent of that new framework is mostly to test low-level functionality\n> that otherwise cannot be easily tested. But here it should actually be\n> quite easy to test things as part of our regular integration-style tests\n> in \"t/t*.sh\", so it would be preferable to write those instead.\n>\n> > 4. Implement strategy for backward compatibility and related tests such as:\n> >\n> > a. Check if Git correctly recognizes the old layout and in case\n> > correctly moves the files according to the new one.\n> >\n> >\n> > Timeline\n> > ------------\n> >\n> > May 1 - 26:\n> > Community bounding Period.\n> > Read Documentation.\n> > Write Backlog.\n> >\n> >\n> > May 27 - July 8:\n> > Implement a new layout for state files.\n> > Write tests.\n> >\n> > July 12 - August 19:\n> > Assess and implement backward compatibility.\n> >\n> > August 19 - Deadline :\n> > Write documentation for the project.\n> >\n> > I can dedicate 3 hours a day during weekdays, and 5 hours during the weekends.\n> >\n> >\n> > Benefits to the Community\n> > -------------------------------------\n> >\n> > How state files dedicated for git-bisect(1) are stored is not ideal.\n> > Having a single directory dedicated to these files, instead of having different\n> > files spread in the Git directory during the bisecting session, is\n> > better and facilitates\n> > even the removal of them after bisecting.  Moreover, as noted by\n> > Phillip (https://lore.kernel.org/git/9c800cd5-8d20-4df7-8834-f74ab000695e@gmail.com/#t),\n> > by aligning the organization of these files to that used for am,\n> > rebase, cherry-pick, etc.,\n> > the repo will have a more coherent and uniform layout.\n> > This will enhance readability and maintainability in general.\n> >\n> > Karthik [1] also expressed  the need of such refactoring as a prerequisite\n> > to introduce new syntax checks for pseudoref in ‘is_pseudoref_syntax()’.\n> >\n> >\n> > [1] See Karthik’s commit: 1eba2240f8ba9f05a47d488bb62041c42c5d4b9c\n>\n> Nicely summarized.\n>\n> >\n> > Biographical information\n> > ----------------------------------\n> >\n> > I’m a former student of Logic and Philosophy who turned to coding\n> > after graduating.\n> > I have been working as a Developer for NTT Data Italia for a year.\n> > I hold a full-time job, but I've seen that it doesn't conflict with\n> > the rules of GSoC\n> > since I'm an open source beginner. I am fully capable of managing my\n> > workload independently,\n> > including my working hours. I know it is not ideal, but I can\n> > definitely work around\n> > my schedule and dedicate time to the project.\n> >\n> > Before, I have contributed small patches to two open source projects:\n> > - Pydata/Sparse: https://github.com/pydata/sparse/pull/611\n> > - Pennylane: https://github.com/PennyLaneAI/pennylane/pull/3959\n>\n> Thanks for your proposal. Please make sure you submit it as a PDF file\n> to the GSoC website soonish, unless you already did that.\n>\n> Patrick\n"},{"id":"491445","messageId":"ZgFfCxkHzTHoRgmX@tanuki","threadId":"61177","inReplyTo":"CAFJh0PTxhDSW1qsnVRrDxmMnp5k16nPGe6RAgrmWow0rgYV+dw@mail.gmail.com","subject":"Re: [RFC][GSoC] Proposal: Refactor git-bisect(1)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-25T11:24:59Z","receivedAt":"2024-03-25T11:25:03Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Mar 25, 2024 at 12:00:58PM +0100, eugenio gigante wrote:\n> > To further stress the point: the biggest challenge of this project is\n> > indeed to find an agreement with the community whether this refactoring\n> > will ultimately be worth it. This will require some good arguing on your\n> > part why exactly you think this is fine and how exactly this will\n> > interact with other implementations of Git like libgit2/JGit/Dulwich. It\n> > may very well happen that ultimately the community decides that this\n> > whole endeavour is not worth it.\n> \n> Yeah, I'll try to expand a bit in this direction. Meanwhile, if you think\n> there are others tools to look into, besides the already cited\n> (libgit2/JGit/Dulwich),\n> like UI interfaces or something else, please let me know.\n> (Maybe GitLab is something to keep in mind?)\n\nI don't think any of the hosting providers would care. GitLab definitely\ndoes not.\n\nPatrick\n"},{"id":"491719","messageId":"12a3b951-39b2-4e9b-9e27-cc29a65cc167@gmail.com","threadId":"61177","inReplyTo":"CAFJh0PS_VB8yv7B1uM5+Ts9PtMFtU5mL4y8UUDORKQcYHSoxPA@mail.gmail.com","subject":"Re: [RFC][GSoC] Proposal: Refactor git-bisect(1)","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2024-03-28T03:23:22Z","receivedAt":"2024-03-28T03:23:27Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Eugenio,\n\nOn 22/03/24 15:56, eugenio gigante wrote:>\n> Timeline\n> ------------\n> \n> May 1 - 26:\n> Community bounding Period.\n> Read Documentation.\n> Write Backlog.\n> \n> \n> May 27 - July 8:\n> Implement a new layout for state files.\n> Write tests.\n> \n> July 12 - August 19:\n> Assess and implement backward compatibility.\n> \n> August 19 - Deadline :\n> Write documentation for the project.\n> \n> I can dedicate 3 hours a day during weekdays, and 5 hours during the weekends.\n> > [ ... snip ... ]\n> \n> \n> Biographical information\n> ----------------------------------\n> \n> I’m a former student of Logic and Philosophy who turned to coding\n> after graduating.\n> I have been working as a Developer for NTT Data Italia for a year.\n> I hold a full-time job, but I've seen that it doesn't conflict with\n> the rules of GSoC\n> since I'm an open source beginner. I am fully capable of managing my\n> workload independently,\n> including my working hours. I know it is not ideal, but I can\n> definitely work around\n> my schedule and dedicate time to the project.\n> \n\nThank you for explicitly mentioning this. Apart from this, if there's \nany specific things you need to clarify regarding your availability, \nplease do so. For instance, if you have any planned vacation periods \nduring which you will be unavailable or some such.\n\n--\nSivaraam\n"},{"id":"491819","messageId":"CAFJh0PRP3kkXpz=PJHT65c7uKpOdkekZAKxWFgxZvHiy33-pbg@mail.gmail.com","threadId":"61177","inReplyTo":"12a3b951-39b2-4e9b-9e27-cc29a65cc167@gmail.com","subject":"Re: [RFC][GSoC] Proposal: Refactor git-bisect(1)","fromName":"eugenio gigante","fromEmail":"giganteeugenio2@gmail.com","sentAt":"2024-03-29T09:05:35Z","receivedAt":"2024-03-29T09:05:46Z","isPatch":false,"sender":{"key":"giganteeugenio2@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116371051?v=4"},"body":"> Thank you for explicitly mentioning this. Apart from this, if there's\n> any specific things you need to clarify regarding your availability,\n> please do so. For instance, if you have any planned vacation periods\n> during which you will be unavailable or some such.\n\nSure!!\n\nIl giorno gio 28 mar 2024 alle ore 04:23 Kaartic Sivaraam\n<kaartic.sivaraam@gmail.com> ha scritto:\n>\n> Hi Eugenio,\n>\n> On 22/03/24 15:56, eugenio gigante wrote:>\n> > Timeline\n> > ------------\n> >\n> > May 1 - 26:\n> > Community bounding Period.\n> > Read Documentation.\n> > Write Backlog.\n> >\n> >\n> > May 27 - July 8:\n> > Implement a new layout for state files.\n> > Write tests.\n> >\n> > July 12 - August 19:\n> > Assess and implement backward compatibility.\n> >\n> > August 19 - Deadline :\n> > Write documentation for the project.\n> >\n> > I can dedicate 3 hours a day during weekdays, and 5 hours during the weekends.\n> > > [ ... snip ... ]\n> >\n> >\n> > Biographical information\n> > ----------------------------------\n> >\n> > I’m a former student of Logic and Philosophy who turned to coding\n> > after graduating.\n> > I have been working as a Developer for NTT Data Italia for a year.\n> > I hold a full-time job, but I've seen that it doesn't conflict with\n> > the rules of GSoC\n> > since I'm an open source beginner. I am fully capable of managing my\n> > workload independently,\n> > including my working hours. I know it is not ideal, but I can\n> > definitely work around\n> > my schedule and dedicate time to the project.\n> >\n>\n> Thank you for explicitly mentioning this. Apart from this, if there's\n> any specific things you need to clarify regarding your availability,\n> please do so. For instance, if you have any planned vacation periods\n> during which you will be unavailable or some such.\n>\n> --\n> Sivaraam\n"}]}