{"thread":{"id":"60399","subject":"[RFC][Outreachy] Seeking Git Community Feedback on My Application","startedAt":"2023-10-19T09:26:40Z","lastAt":"2023-10-29T14:43:43Z","messageCount":9,"participants":["Isoken Ibizugbe","Christian Couder","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"483475","messageId":"CAJHH8bEfM8KmwhHX_Fmcb0A2zpr8L75vgNhfvZy-uitpSXNUvQ@mail.gmail.com","threadId":"60399","inReplyTo":null,"subject":"[RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Isoken Ibizugbe","fromEmail":"isokenjune@gmail.com","sentAt":"2023-10-19T09:25:07Z","receivedAt":"2023-10-19T09:26:40Z","isPatch":false,"sender":{"key":"isokenjune@gmail.com","avatar":"https://avatars.githubusercontent.com/u/127752393?v=4"},"body":"Dear Git Community and Mentors,\n\nI hope you're doing well. I'm excited to share my application draft\nfor the Outreachy program with the Git project. Your feedback is\ninvaluable, and I'm eager to align the project with the community's\nneeds. Please review the attached draft and share your insights.\n\nThank you for your support.\n\nProject Application\n----\n\nAbout Me:\n\nMy name is Isoken June Ibizugbe, my language is primarily English, and\nI am a resident of Nigeria. I am a student at an online coding school\ncalled African Leadership Xcelerator (ALX), participating in the\nsoftware engineering program.\n\nWhat project am I applying for?\n\nMoving Existing Tests to a Unit Testing Framework\n\nWhy am I interested in working with the Git chosen project?\n\nGit has been a cornerstone for software development, enabling\ndevelopers worldwide to collaborate, innovate, and create exceptional\nsoftware. I would say without Git, my journey to pursuing my software\nengineering career would be impossible, as I use it almost every day.\nYet, in this constantly evolving landscape, there is always room for\nimprovement, even in a well-established project. The Git project\ncurrently relies on end-to-end tests, and this is where I see an\nopportunity to make a profound impact. Being able to test libraries in\nisolation via unit tests or mocks speeds up determining the root cause\nof bugs. I am deeply passionate about contributing to this project and\nfirmly believe in the power of open-source software and the collective\nintelligence of the community. A successful completion of this project\nwill significantly improve Git's testing capabilities and bring the\nbenefits of fewer errors, faster work and better testing for all\nparts.\n\nMy motivation for joining the Git community stemmed from my desire to\nimmerse myself in the world of open-source software and, ultimately,\nto become a part of the Outreachy program. My time spent contributing\nto Git has been nothing short of transformative. It has been a\nremarkable learning experience that has introduced me to a new form of\ncollaboration using a mailing list and contributing through patches\nrather than the typical Pull Request (PR). This collaborative\natmosphere has been pivotal in my growth as a developer, and I am\neager to continue this journey, making meaningful contributions to\nthis remarkable open-source project.\n\nContributions to Git\n\nI have actively participated in Git's mailing list discussions and\ncontributed to a micro-project;\n\n- builtin/branch.c: Adjust error messages such as die(), error(), and\nwarning() messages used in branch, to conform to coding guidelines\n(https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n- Implemented changes to fix broken tests based on reviews from the\ncommunity (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n- In review.\n\nProject Goals:\n\n- Improve Testing Efficiency: Transitioning from end-to-end tests to\nunit tests will enable more efficient testing of error conditions.\n- Codebase Stability: Unit tests enhance code stability and facilitate\neasier debugging through isolation.\n- Simplify Testing: Writing unit tests in pure C simplifies test\nsetup, data passing, and reduces testing runtime by eliminating\nseparate processes for each test.\n\nProject Milestones:\n\n- Add useful tests of library-like code\n- Integrate with stdlib work\n- Run alongside regular make test target\n\nProject Timeline:\n\n1. Oct 2 - Nov 20: Community Bonding\n\n- Understanding the structure of Git\n- Getting familiar with the code\n\n2. Dec 4 - Jan 15: Add useful tests of library-like code\n\n- Identify and document the current state of the tests in the Git\nt/helper directory.\n- Confirm the licensing and compatibility requirements for the chosen\nunit testing framework.\n- Develop unit tests for these library-like components.\n- Execute the tests and ensure they cover various scenarios, including\nerror conditions.\n- Run the tests and address any initial issues or bugs to ensure they\nwork as intended.\n- Document the new tests and their coverage.\n- Seek feedback  and support from mentors and the Git community\n\n3. Jan 15 - Feb 15: Integrate with Stdlib Work\n\n- Collaborate with the team working on standard library integration.\n- Ensure that the tests for library-like code align with stdlib work.\n- Verify that the tests effectively check the compatibility and\ninteraction of the code with standard libraries.\n- Gather feedback and insights from the Git community on the\nintegrated tests, addressing any concerns or suggestions.\n\n4. Feb 15 - March 1: Run Alongside Regular 'make test' Target and finalize\n\n- Configure the testing framework to run alongside the regular 'make\ntest' target.\n- Ensure that the new tests are included in the standard testing suite.\n- Execute 'make test' with the new tests and verify that they pass successfully.\n- Document the integration process and how the new tests are included\nin the standard testing procedure.\n- Perform comprehensive testing of the entire unit testing framework.\n- Ensure all migrated tests are working correctly within the new framework.\n- Document the entire process of migrating Git's tests\n- Prepare a final project report\n\nTechnical Requirements\n\nAccording to the documentation on the unit test project\n(https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc),\nthe suggested best framework for the Git project is the \"Custom TAP\nframework\" (Phillip Wood's TAP implementation), as it aligns with\nGit's licensing requirements, is vendorable, and can be customized by\nGit's developers as needed, but it may require some additional\ndevelopment work for features like parallel execution and mock\nsupport, but it offers a strong foundation for unit testing within the\nGit project.\n\nRelevant Projects\n\nSimple shell -  A project based on emulating a shell. It was a\ncollaborative project which we managed using Git.\n(https://github.com/Junie06/simple_shell).\nThis project was written in C, which allowed me to apply my C language\nknowledge, essential for Git projects.\nI'm proficient in using Shell for scripting, redirections, and\npermissions, as shown in my work\n(https://github.com/Junie06/alx-system_engineering-devops).\nCreating the simple shell project deepened my understanding of how\nshells work, and I even attempted to replicate a shell environment.\nCollaborating on the Simple Shell project reinforced my Git skills.\n"},{"id":"483540","messageId":"CAJHH8bHOYz6Y5=jwcH_F6gsUkvc+FM6bDWLPCRndZvkkfAQ7-Q@mail.gmail.com","threadId":"60399","inReplyTo":"CAJHH8bEfM8KmwhHX_Fmcb0A2zpr8L75vgNhfvZy-uitpSXNUvQ@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Isoken Ibizugbe","fromEmail":"isokenjune@gmail.com","sentAt":"2023-10-20T04:31:11Z","receivedAt":"2023-10-20T04:32:43Z","isPatch":false,"sender":{"key":"isokenjune@gmail.com","avatar":"https://avatars.githubusercontent.com/u/127752393?v=4"},"body":"On Thu, Oct 19, 2023 at 10:25 AM Isoken Ibizugbe <isokenjune@gmail.com> wrote:\n>\n> Dear Git Community and Mentors,\n>\n> I hope you're doing well. I'm excited to share my application draft\n> for the Outreachy program with the Git project. Your feedback is\n> invaluable, and I'm eager to align the project with the community's\n> needs. Please review the attached draft and share your insights.\n>\n> Thank you for your support.\nHello Christian, I would appreciate a review from you.\n>\n> Project Application\n> ----\n>\n> About Me:\n>\n> My name is Isoken June Ibizugbe, my language is primarily English, and\n> I am a resident of Nigeria. I am a student at an online coding school\n> called African Leadership Xcelerator (ALX), participating in the\n> software engineering program.\n>\n> What project am I applying for?\n>\n> Moving Existing Tests to a Unit Testing Framework\n>\n> Why am I interested in working with the Git chosen project?\n>\n> Git has been a cornerstone for software development, enabling\n> developers worldwide to collaborate, innovate, and create exceptional\n> software. I would say without Git, my journey to pursuing my software\n> engineering career would be impossible, as I use it almost every day.\n> Yet, in this constantly evolving landscape, there is always room for\n> improvement, even in a well-established project. The Git project\n> currently relies on end-to-end tests, and this is where I see an\n> opportunity to make a profound impact. Being able to test libraries in\n> isolation via unit tests or mocks speeds up determining the root cause\n> of bugs. I am deeply passionate about contributing to this project and\n> firmly believe in the power of open-source software and the collective\n> intelligence of the community. A successful completion of this project\n> will significantly improve Git's testing capabilities and bring the\n> benefits of fewer errors, faster work and better testing for all\n> parts.\n>\n> My motivation for joining the Git community stemmed from my desire to\n> immerse myself in the world of open-source software and, ultimately,\n> to become a part of the Outreachy program. My time spent contributing\n> to Git has been nothing short of transformative. It has been a\n> remarkable learning experience that has introduced me to a new form of\n> collaboration using a mailing list and contributing through patches\n> rather than the typical Pull Request (PR). This collaborative\n> atmosphere has been pivotal in my growth as a developer, and I am\n> eager to continue this journey, making meaningful contributions to\n> this remarkable open-source project.\n>\n> Contributions to Git\n>\n> I have actively participated in Git's mailing list discussions and\n> contributed to a micro-project;\n>\n> - builtin/branch.c: Adjust error messages such as die(), error(), and\n> warning() messages used in branch, to conform to coding guidelines\n> (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n> - Implemented changes to fix broken tests based on reviews from the\n> community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n> - In review.\n>\n> Project Goals:\n>\n> - Improve Testing Efficiency: Transitioning from end-to-end tests to\n> unit tests will enable more efficient testing of error conditions.\n> - Codebase Stability: Unit tests enhance code stability and facilitate\n> easier debugging through isolation.\n> - Simplify Testing: Writing unit tests in pure C simplifies test\n> setup, data passing, and reduces testing runtime by eliminating\n> separate processes for each test.\n>\n> Project Milestones:\n>\n> - Add useful tests of library-like code\n> - Integrate with stdlib work\n> - Run alongside regular make test target\n>\n> Project Timeline:\n>\n> 1. Oct 2 - Nov 20: Community Bonding\n>\n> - Understanding the structure of Git\n> - Getting familiar with the code\n>\n> 2. Dec 4 - Jan 15: Add useful tests of library-like code\n>\n> - Identify and document the current state of the tests in the Git\n> t/helper directory.\n> - Confirm the licensing and compatibility requirements for the chosen\n> unit testing framework.\n> - Develop unit tests for these library-like components.\n> - Execute the tests and ensure they cover various scenarios, including\n> error conditions.\n> - Run the tests and address any initial issues or bugs to ensure they\n> work as intended.\n> - Document the new tests and their coverage.\n> - Seek feedback  and support from mentors and the Git community\n>\n> 3. Jan 15 - Feb 15: Integrate with Stdlib Work\n>\n> - Collaborate with the team working on standard library integration.\n> - Ensure that the tests for library-like code align with stdlib work.\n> - Verify that the tests effectively check the compatibility and\n> interaction of the code with standard libraries.\n> - Gather feedback and insights from the Git community on the\n> integrated tests, addressing any concerns or suggestions.\n>\n> 4. Feb 15 - March 1: Run Alongside Regular 'make test' Target and finalize\n>\n> - Configure the testing framework to run alongside the regular 'make\n> test' target.\n> - Ensure that the new tests are included in the standard testing suite.\n> - Execute 'make test' with the new tests and verify that they pass successfully.\n> - Document the integration process and how the new tests are included\n> in the standard testing procedure.\n> - Perform comprehensive testing of the entire unit testing framework.\n> - Ensure all migrated tests are working correctly within the new framework.\n> - Document the entire process of migrating Git's tests\n> - Prepare a final project report\n>\n> Technical Requirements\n>\n> According to the documentation on the unit test project\n> (https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc),\n> the suggested best framework for the Git project is the \"Custom TAP\n> framework\" (Phillip Wood's TAP implementation), as it aligns with\n> Git's licensing requirements, is vendorable, and can be customized by\n> Git's developers as needed, but it may require some additional\n> development work for features like parallel execution and mock\n> support, but it offers a strong foundation for unit testing within the\n> Git project.\n>\n> Relevant Projects\n>\n> Simple shell -  A project based on emulating a shell. It was a\n> collaborative project which we managed using Git.\n> (https://github.com/Junie06/simple_shell).\n> This project was written in C, which allowed me to apply my C language\n> knowledge, essential for Git projects.\n> I'm proficient in using Shell for scripting, redirections, and\n> permissions, as shown in my work\n> (https://github.com/Junie06/alx-system_engineering-devops).\n> Creating the simple shell project deepened my understanding of how\n> shells work, and I even attempted to replicate a shell environment.\n> Collaborating on the Simple Shell project reinforced my Git skills.\n"},{"id":"483676","messageId":"CAP8UFD22EpdBU8HJqFM+=75EBABOTf5a0q+KsbzLK+XTEGSkPw@mail.gmail.com","threadId":"60399","inReplyTo":"CAJHH8bEfM8KmwhHX_Fmcb0A2zpr8L75vgNhfvZy-uitpSXNUvQ@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-10-23T14:24:03Z","receivedAt":"2023-10-23T14:24:20Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Oct 19, 2023 at 11:26 AM Isoken Ibizugbe <isokenjune@gmail.com> wrote:\n>\n> Dear Git Community and Mentors,\n>\n> I hope you're doing well. I'm excited to share my application draft\n> for the Outreachy program with the Git project. Your feedback is\n> invaluable, and I'm eager to align the project with the community's\n> needs. Please review the attached draft and share your insights.\n\nThanks for your project application!\n\n[...]\n\n> Why am I interested in working with the Git chosen project?\n>\n> Git has been a cornerstone for software development, enabling\n> developers worldwide to collaborate, innovate, and create exceptional\n> software. I would say without Git, my journey to pursuing my software\n> engineering career would be impossible, as I use it almost every day.\n> Yet, in this constantly evolving landscape, there is always room for\n> improvement, even in a well-established project. The Git project\n> currently relies on end-to-end tests, and this is where I see an\n> opportunity to make a profound impact. Being able to test libraries in\n> isolation via unit tests or mocks speeds up determining the root cause\n> of bugs. I am deeply passionate about contributing to this project and\n> firmly believe in the power of open-source software and the collective\n> intelligence of the community. A successful completion of this project\n> will significantly improve Git's testing capabilities and bring the\n> benefits of fewer errors, faster work and better testing for all\n> parts.\n\nOk.\n\n[...]\n\n> Contributions to Git\n>\n> I have actively participated in Git's mailing list discussions and\n> contributed to a micro-project;\n>\n> - builtin/branch.c: Adjust error messages such as die(), error(), and\n> warning() messages used in branch, to conform to coding guidelines\n> (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n> - Implemented changes to fix broken tests based on reviews from the\n> community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n> - In review.\n\nNice!\n\n> Project Goals:\n>\n> - Improve Testing Efficiency: Transitioning from end-to-end tests to\n> unit tests will enable more efficient testing of error conditions.\n> - Codebase Stability: Unit tests enhance code stability and facilitate\n> easier debugging through isolation.\n> - Simplify Testing: Writing unit tests in pure C simplifies test\n> setup, data passing, and reduces testing runtime by eliminating\n> separate processes for each test.\n\nOk.\n\n> Project Milestones:\n>\n> - Add useful tests of library-like code\n> - Integrate with stdlib work\n\nNot sure what you call \"stdlib\" here.\n\n> - Run alongside regular make test target\n>\n> Project Timeline:\n>\n> 1. Oct 2 - Nov 20: Community Bonding\n>\n> - Understanding the structure of Git\n> - Getting familiar with the code\n\nI think some of this time is also spent on working on a microproject,\nwriting an application and perhaps doing other things that regular Git\ndevelopers do.\n\n> 2. Dec 4 - Jan 15: Add useful tests of library-like code\n>\n> - Identify and document the current state of the tests in the Git\n> t/helper directory.\n\nIt would be nice if you could already take a look at that and tell us\nabout it in your application. There are different things in t/helper.\nSome are worth porting and others are not. You might not want (or have\ntime to) to classify everything right now, but if you can identify a\nfew of each kind, and use those, or just one of them, as an example,\nthat would be great.\n\n> - Confirm the licensing and compatibility requirements for the chosen\n> unit testing framework.\n\nI think those who have been working on the unit test framework have\nalready done this.\n\n> - Develop unit tests for these library-like components.\n\nNot sure what are \"these library-like components\". An example would\nperhaps help.\n\n> - Execute the tests and ensure they cover various scenarios, including\n> error conditions.\n> - Run the tests and address any initial issues or bugs to ensure they\n> work as intended.\n\nOk.\n\n> - Document the new tests and their coverage.\n\nWhat kind of documentation would that be?\n\n> - Seek feedback  and support from mentors and the Git community\n>\n> 3. Jan 15 - Feb 15: Integrate with Stdlib Work\n>\n> - Collaborate with the team working on standard library integration.\n\nNot sure what \"standard library\". Actually, maybe you are talking\nabout the goal of having a \"standard library\" implementation for Git\nwhich is described in this report from the Virtual Contributor's\nSummit:\n\nhttps://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/\n\nIt's true that the unit test framework would help with that goal. So\nyeah maybe you will have to collaborate with the team working on that\ngoal. I am not sure at what step the work on this library will be when\nthe internship will start though.\n\n> - Ensure that the tests for library-like code align with stdlib work.\n> - Verify that the tests effectively check the compatibility and\n> interaction of the code with standard libraries.\n> - Gather feedback and insights from the Git community on the\n> integrated tests, addressing any concerns or suggestions.\n\nOk, but I think it would be more interesting to follow the steps with\nan example test.\n\n> 4. Feb 15 - March 1: Run Alongside Regular 'make test' Target and finalize\n>\n> - Configure the testing framework to run alongside the regular 'make\n> test' target.\n\nI think others will likely take care of that sooner.\n\n> - Ensure that the new tests are included in the standard testing suite.\n> - Execute 'make test' with the new tests and verify that they pass successfully.\n> - Document the integration process and how the new tests are included\n> in the standard testing procedure.\n> - Perform comprehensive testing of the entire unit testing framework.\n> - Ensure all migrated tests are working correctly within the new framework.\n> - Document the entire process of migrating Git's tests\n> - Prepare a final project report\n\nOk, but here also following an example test would be more interesting.\n\n> Technical Requirements\n>\n> According to the documentation on the unit test project\n> (https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc),\n> the suggested best framework for the Git project is the \"Custom TAP\n> framework\" (Phillip Wood's TAP implementation), as it aligns with\n> Git's licensing requirements, is vendorable, and can be customized by\n> Git's developers as needed, but it may require some additional\n> development work for features like parallel execution and mock\n> support, but it offers a strong foundation for unit testing within the\n> Git project.\n\nYeah, right. Thanks for summarizing that document!\n\n> Relevant Projects\n>\n> Simple shell -  A project based on emulating a shell. It was a\n> collaborative project which we managed using Git.\n> (https://github.com/Junie06/simple_shell).\n> This project was written in C, which allowed me to apply my C language\n> knowledge, essential for Git projects.\n> I'm proficient in using Shell for scripting, redirections, and\n> permissions, as shown in my work\n> (https://github.com/Junie06/alx-system_engineering-devops).\n> Creating the simple shell project deepened my understanding of how\n> shells work, and I even attempted to replicate a shell environment.\n> Collaborating on the Simple Shell project reinforced my Git skills.\n\nOk, nice!\n\nBest,\nChristian.\n"},{"id":"483854","messageId":"CAJHH8bH0gp9tbDJ4DYk3jkNPD5_dZ9s62D9ae3q33aBP0ZL9Lg@mail.gmail.com","threadId":"60399","inReplyTo":"CAP8UFD22EpdBU8HJqFM+=75EBABOTf5a0q+KsbzLK+XTEGSkPw@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Isoken Ibizugbe","fromEmail":"isokenjune@gmail.com","sentAt":"2023-10-25T12:45:20Z","receivedAt":"2023-10-25T12:46:56Z","isPatch":false,"sender":{"key":"isokenjune@gmail.com","avatar":"https://avatars.githubusercontent.com/u/127752393?v=4"},"body":"On Mon, Oct 23, 2023 at 3:24 PM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> On Thu, Oct 19, 2023 at 11:26 AM Isoken Ibizugbe <isokenjune@gmail.com> wrote:\n> >\n> > Dear Git Community and Mentors,\n> >\n> > I hope you're doing well. I'm excited to share my application draft\n> > for the Outreachy program with the Git project. Your feedback is\n> > invaluable, and I'm eager to align the project with the community's\n> > needs. Please review the attached draft and share your insights.\n>\n> Thanks for your project application!\n>\n> [...]\n>\n> > Why am I interested in working with the Git chosen project?\n> >\n> > Git has been a cornerstone for software development, enabling\n> > developers worldwide to collaborate, innovate, and create exceptional\n> > software. I would say without Git, my journey to pursuing my software\n> > engineering career would be impossible, as I use it almost every day.\n> > Yet, in this constantly evolving landscape, there is always room for\n> > improvement, even in a well-established project. The Git project\n> > currently relies on end-to-end tests, and this is where I see an\n> > opportunity to make a profound impact. Being able to test libraries in\n> > isolation via unit tests or mocks speeds up determining the root cause\n> > of bugs. I am deeply passionate about contributing to this project and\n> > firmly believe in the power of open-source software and the collective\n> > intelligence of the community. A successful completion of this project\n> > will significantly improve Git's testing capabilities and bring the\n> > benefits of fewer errors, faster work and better testing for all\n> > parts.\n>\n> Ok.\n>\n> [...]\n>\n> > Contributions to Git\n> >\n> > I have actively participated in Git's mailing list discussions and\n> > contributed to a micro-project;\n> >\n> > - builtin/branch.c: Adjust error messages such as die(), error(), and\n> > warning() messages used in branch, to conform to coding guidelines\n> > (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n> > - Implemented changes to fix broken tests based on reviews from the\n> > community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)\n> > - In review.\n>\n> Nice!\n>\n> > Project Goals:\n> >\n> > - Improve Testing Efficiency: Transitioning from end-to-end tests to\n> > unit tests will enable more efficient testing of error conditions.\n> > - Codebase Stability: Unit tests enhance code stability and facilitate\n> > easier debugging through isolation.\n> > - Simplify Testing: Writing unit tests in pure C simplifies test\n> > setup, data passing, and reduces testing runtime by eliminating\n> > separate processes for each test.\n>\n> Ok.\n>\n> > Project Milestones:\n> >\n> > - Add useful tests of library-like code\n> > - Integrate with stdlib work\n>\n> Not sure what you call \"stdlib\" here.\n>\n> > - Run alongside regular make test target\n> >\n> > Project Timeline:\n> >\n> > 1. Oct 2 - Nov 20: Community Bonding\n> >\n> > - Understanding the structure of Git\n> > - Getting familiar with the code\n>\n> I think some of this time is also spent on working on a microproject,\n> writing an application and perhaps doing other things that regular Git\n> developers do.\n>\n> > 2. Dec 4 - Jan 15: Add useful tests of library-like code\n> >\n> > - Identify and document the current state of the tests in the Git\n> > t/helper directory.\n>\n> It would be nice if you could already take a look at that and tell us\n> about it in your application. There are different things in t/helper.\n> Some are worth porting and others are not. You might not want (or have\n> time to) to classify everything right now, but if you can identify a\n> few of each kind, and use those, or just one of them, as an example,\n> that would be great.\n>\n> > - Confirm the licensing and compatibility requirements for the chosen\n> > unit testing framework.\n>\n> I think those who have been working on the unit test framework have\n> already done this.\n\nThank you for the review. I have made changes to the project plan and\nit emphasizes the critical tasks of identifying, selecting, and\nporting tests, making it more concise and aligned with the project's\nscope.\n\n- Community Bonding (Oct 2 - Nov 20): Microproject contribution, Git\nproject application, get familiar with the Git codebase and testing\necosystem.\n-Identify and Select Tests: Identify and prioritize tests worth\nporting, and document the selected tests. (I would classify tests that\nare worth porting according to the following for now;\n\nRelevance: Prioritize tests that are relevant to the current Git codebase.\nCoverage: Focus on tests that cover core functionality or critical code paths.\nUsage Frequency: Port tests that are frequently used or run in Git's\ndevelopment process.\nIsolation: Choose tests that can be easily ported and run independently.\n\n- Write Unit Tests: Write unit tests for the identified test cases\nusing the Git custom test framework.\n- Port Existing Tests: Port selected test cases from the t/helper\ndirectory to the unit testing framework, by modifying them to work\nwithin the custom TAP framework.\n- Test Execution and Debugging: Execute the newly written unit tests\nand the ported tests using the test framework.\n- Seek Feedback: Share the progress with mentors and the Git\ncommunity, and address any concerns or suggestions provided by the\ncommunity.\n- Documentation and Reporting: Document the entire process of\nmigrating Git's tests to the unit testing framework, and prepare a\nfinal project report summarizing the work done, challenges faced, and\nlessons learned.\n\nWhat is the custom TAP framework?\n\nAccording to this patch\n(https://lore.kernel.org/git/ca284c575ece0aee7149641d5fb1977ccd7e7873.1692229626.git.steadmon@google.com/)\nby Phillip Wood, which contains an example implementation for writing\nunit tests with TAP output. The custom TAP framework is a Test\nAnything Protocol (TAP) framework that allows for clear reporting of\ntest results, aiding in debugging and troubleshooting.\n\nThe framework contains the following features:\n\n- Test Structure: Unit tests are defined as functions containing\nmultiple checks. The tests are run using the TEST() macro. If any\nchecks within a test fail, the entire test is marked as failed.\n- Output Format: The output of the test program follows the TAP\nformat. It includes a series of messages describing the test's status.\nFor passed tests, it reports \"ok,\" and for failed tests, it reports\n\"not ok.\" Each test is numbered, e.g., \"ok 1 - static initialization\nworks,\" to indicate success or failure.\n- Check Functions: Several check functions are available, including\ncheck() for boolean conditions, check_int(), check_uint(), and\ncheck_char() for comparing values using various operators. check_str()\nis used to compare strings.\n- Skipping Tests: Tests can be skipped using test_skip() and can\ninclude a reason for skipping, which is printed as part of the report.\n- Diagnostic Messages: Tests can generate diagnostic messages using\ntest_msg() to provide additional context or explanations for test\nfailures.\n- Planned Failing Tests: Tests that are known to fail can be marked\nwith TEST_TODO(). These tests will still run, and the failures will be\nreported, but they will not cause the entire suite to fail.\n- Building and Running: The unit tests can be built with \"make\nunit-tests\" (with some additional Makefile changes), and they can be\nexecuted manually or using a tool like prove.\n\nUsing the formerly given criteria, test-ctype.c is suitable for\nporting because it tests character type checks used extensively in\nGit. These tests cover various character types and their expected\nbehaviour, ensuring the correctness and reliability of Git's\noperations, and test-ctype.c isolation makes it suitable for porting\nwithout relying on multiple libraries.\n\n\nHere is a sample of the implementation of how I would write the unit\ntest following the custom TAP framework taking t/helper/test-ctype.c\n\n- Create and rename the new .c file;\nI would rename it according to the convention done in the t/unit-test\ndirectory, by starting the name with a “t-” prefix e.g t-ctype.c\n\n- Document the tests and include the necessary headers:\n/**\n *Tests the behavior of ctype\n *functions\n*/\n#include \"test-lib.h\"\n#include \"ctype.h\"\n\n- Define test functions:\n#define DIGIT \"0123456789\"\n\nstatic void t_digit_type(void)\n{\n    int i;\n    const char *digits = DIGIT;\n    for (i = 0; digits[i]; i++)\n   {\n         check_int(isdigit(digits[i]), ==, 0);\n   }\n\n- Include main function which will call the test functions using the TEST macro;\nint main(void)\n{\n    TEST(t_digit_type(), \"Character is a digit\");\n    return test_done();\n}\n\n- Run the tests:\n‘make && make’ unit-tests can be used build and run the unit tests\nOr run the test binaries directly:\n./t/unit-tests/t-ctype.c\n\nThe Makefile will be modified to add the file;\nUNIT_TEST_PROGRAMS += t-ctype\nThe test output will be in the TAP format and will indicate which\ntests passed(ok) and which failed(not ok), along with diagnostic\nmessages in case of failures.\n\nok 1 - Character is a digit\n\n1..1\n\n>\n> > - Develop unit tests for these library-like components.\n>\n> Not sure what are \"these library-like components\". An example would\n> perhaps help.\n>\n> > - Execute the tests and ensure they cover various scenarios, including\n> > error conditions.\n> > - Run the tests and address any initial issues or bugs to ensure they\n> > work as intended.\n>\n> Ok.\n>\n> > - Document the new tests and their coverage.\n>\n> What kind of documentation would that be?\n>\n> > - Seek feedback  and support from mentors and the Git community\n> >\n> > 3. Jan 15 - Feb 15: Integrate with Stdlib Work\n> >\n> > - Collaborate with the team working on standard library integration.\n>\n> Not sure what \"standard library\". Actually, maybe you are talking\n> about the goal of having a \"standard library\" implementation for Git\n> which is described in this report from the Virtual Contributor's\n> Summit:\n>\n> https://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/\n>\n> It's true that the unit test framework would help with that goal. So\n> yeah maybe you will have to collaborate with the team working on that\n> goal. I am not sure at what step the work on this library will be when\n> the internship will start though.\n>\n> > - Ensure that the tests for library-like code align with stdlib work.\n> > - Verify that the tests effectively check the compatibility and\n> > interaction of the code with standard libraries.\n> > - Gather feedback and insights from the Git community on the\n> > integrated tests, addressing any concerns or suggestions.\n>\n> Ok, but I think it would be more interesting to follow the steps with\n> an example test.\n>\n> > 4. Feb 15 - March 1: Run Alongside Regular 'make test' Target and finalize\n> >\n> > - Configure the testing framework to run alongside the regular 'make\n> > test' target.\n>\n> I think others will likely take care of that sooner.\n>\n> > - Ensure that the new tests are included in the standard testing suite.\n> > - Execute 'make test' with the new tests and verify that they pass successfully.\n> > - Document the integration process and how the new tests are included\n> > in the standard testing procedure.\n> > - Perform comprehensive testing of the entire unit testing framework.\n> > - Ensure all migrated tests are working correctly within the new framework.\n> > - Document the entire process of migrating Git's tests\n> > - Prepare a final project report\n>\n> Ok, but here also following an example test would be more interesting.\n\n>\n> > Technical Requirements\n> >\n> > According to the documentation on the unit test project\n> > (https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc),\n> > the suggested best framework for the Git project is the \"Custom TAP\n> > framework\" (Phillip Wood's TAP implementation), as it aligns with\n> > Git's licensing requirements, is vendorable, and can be customized by\n> > Git's developers as needed, but it may require some additional\n> > development work for features like parallel execution and mock\n> > support, but it offers a strong foundation for unit testing within the\n> > Git project.\n>\n> Yeah, right. Thanks for summarizing that document!\n>\n> > Relevant Projects\n> >\n> > Simple shell -  A project based on emulating a shell. It was a\n> > collaborative project which we managed using Git.\n> > (https://github.com/Junie06/simple_shell).\n> > This project was written in C, which allowed me to apply my C language\n> > knowledge, essential for Git projects.\n> > I'm proficient in using Shell for scripting, redirections, and\n> > permissions, as shown in my work\n> > (https://github.com/Junie06/alx-system_engineering-devops).\n> > Creating the simple shell project deepened my understanding of how\n> > shells work, and I even attempted to replicate a shell environment.\n> > Collaborating on the Simple Shell project reinforced my Git skills.\n>\n> Ok, nice!\n>\n> Best,\n> Christian.\n"},{"id":"484019","messageId":"CAP8UFD16OAPiRFJfjZN=soAe3WzDBteyvzv-b3CD67jz6Haqyg@mail.gmail.com","threadId":"60399","inReplyTo":"CAJHH8bH0gp9tbDJ4DYk3jkNPD5_dZ9s62D9ae3q33aBP0ZL9Lg@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-10-28T08:07:25Z","receivedAt":"2023-10-28T08:07:41Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Oct 25, 2023 at 2:46 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:\n\n> Thank you for the review. I have made changes to the project plan and\n> it emphasizes the critical tasks of identifying, selecting, and\n> porting tests, making it more concise and aligned with the project's\n> scope.\n\nGood.\n\n> - Community Bonding (Oct 2 - Nov 20): Microproject contribution, Git\n> project application, get familiar with the Git codebase and testing\n> ecosystem.\n> -Identify and Select Tests: Identify and prioritize tests worth\n> porting, and document the selected tests. (I would classify tests that\n> are worth porting according to the following for now;\n>\n> Relevance: Prioritize tests that are relevant to the current Git codebase.\n> Coverage: Focus on tests that cover core functionality or critical code paths.\n> Usage Frequency: Port tests that are frequently used or run in Git's\n> development process.\n> Isolation: Choose tests that can be easily ported and run independently.\n\nI think the main issue with identification is that now in t/helper/ we\nhave both:\n\n  1) code that implements helpers that are used by the end-to-end\ntests scripts written in shell and named \"t/tXXXX-*.sh\" where XXXX is\na number, and\n  2) code that implements unit tests for some C code in the code base.\n\nSo I think only 2) should be ported to the unit test framework, and 1)\nshould not be ported and stay in t/helper/.\n\n> - Write Unit Tests: Write unit tests for the identified test cases\n> using the Git custom test framework.\n> - Port Existing Tests: Port selected test cases from the t/helper\n> directory to the unit testing framework, by modifying them to work\n> within the custom TAP framework.\n> - Test Execution and Debugging: Execute the newly written unit tests\n> and the ported tests using the test framework.\n> - Seek Feedback: Share the progress with mentors and the Git\n> community, and address any concerns or suggestions provided by the\n> community.\n> - Documentation and Reporting: Document the entire process of\n> migrating Git's tests to the unit testing framework, and prepare a\n> final project report summarizing the work done, challenges faced, and\n> lessons learned.\n>\n> What is the custom TAP framework?\n>\n> According to this patch\n> (https://lore.kernel.org/git/ca284c575ece0aee7149641d5fb1977ccd7e7873.1692229626.git.steadmon@google.com/)\n> by Phillip Wood, which contains an example implementation for writing\n> unit tests with TAP output. The custom TAP framework is a Test\n> Anything Protocol (TAP) framework that allows for clear reporting of\n> test results, aiding in debugging and troubleshooting.\n\nOk. Our end-to-end tests scripts written in shell already use TAP,\nthat's why it's nice to have unit tests also using TAP.\n\n> The framework contains the following features:\n>\n> - Test Structure: Unit tests are defined as functions containing\n> multiple checks. The tests are run using the TEST() macro. If any\n> checks within a test fail, the entire test is marked as failed.\n> - Output Format: The output of the test program follows the TAP\n> format. It includes a series of messages describing the test's status.\n> For passed tests, it reports \"ok,\" and for failed tests, it reports\n> \"not ok.\" Each test is numbered, e.g., \"ok 1 - static initialization\n> works,\" to indicate success or failure.\n> - Check Functions: Several check functions are available, including\n> check() for boolean conditions, check_int(), check_uint(), and\n> check_char() for comparing values using various operators. check_str()\n> is used to compare strings.\n> - Skipping Tests: Tests can be skipped using test_skip() and can\n> include a reason for skipping, which is printed as part of the report.\n> - Diagnostic Messages: Tests can generate diagnostic messages using\n> test_msg() to provide additional context or explanations for test\n> failures.\n> - Planned Failing Tests: Tests that are known to fail can be marked\n> with TEST_TODO(). These tests will still run, and the failures will be\n> reported, but they will not cause the entire suite to fail.\n> - Building and Running: The unit tests can be built with \"make\n> unit-tests\" (with some additional Makefile changes), and they can be\n> executed manually or using a tool like prove.\n\nOk.\n\n> Using the formerly given criteria, test-ctype.c is suitable for\n> porting because it tests character type checks used extensively in\n> Git. These tests cover various character types and their expected\n> behaviour, ensuring the correctness and reliability of Git's\n> operations, and test-ctype.c isolation makes it suitable for porting\n> without relying on multiple libraries.\n\nOk.\n\n> Here is a sample of the implementation of how I would write the unit\n> test following the custom TAP framework taking t/helper/test-ctype.c\n>\n> - Create and rename the new .c file;\n> I would rename it according to the convention done in the t/unit-test\n> directory, by starting the name with a “t-” prefix e.g t-ctype.c\n>\n> - Document the tests and include the necessary headers:\n> /**\n>  *Tests the behavior of ctype\n>  *functions\n> */\n> #include \"test-lib.h\"\n> #include \"ctype.h\"\n>\n> - Define test functions:\n> #define DIGIT \"0123456789\"\n>\n> static void t_digit_type(void)\n> {\n>     int i;\n>     const char *digits = DIGIT;\n>     for (i = 0; digits[i]; i++)\n>    {\n>          check_int(isdigit(digits[i]), ==, 0);\n>    }\n\nThis tests that isdigit() returns 0 for each of the characters in\n\"0123456789\", but first I think isdigit() should return 1, not 0 for\nthose characters.\n\nAnd second, I think the test should check the value returned by\nisdigit() for each of the 256 possible values of a char, not just for\nthe characters in \"0123456789\".\n\ntest-ctype.c is doing the right thing regarding those 2 issues.\n\n> - Include main function which will call the test functions using the TEST macro;\n> int main(void)\n> {\n>     TEST(t_digit_type(), \"Character is a digit\");\n>     return test_done();\n> }\n>\n> - Run the tests:\n> ‘make && make’ unit-tests can be used build and run the unit tests\n> Or run the test binaries directly:\n> ./t/unit-tests/t-ctype.c\n>\n> The Makefile will be modified to add the file;\n> UNIT_TEST_PROGRAMS += t-ctype\n> The test output will be in the TAP format and will indicate which\n> tests passed(ok) and which failed(not ok), along with diagnostic\n> messages in case of failures.\n>\n> ok 1 - Character is a digit\n>\n> 1..1\n\nYeah, this looks right.\n\nThanks,\nChristian.\n"},{"id":"484021","messageId":"CAJHH8bGK28Fc+VG3uxgC5sGgFEAw6_6AEtusgmw7c4Vz0iGF_g@mail.gmail.com","threadId":"60399","inReplyTo":"CAP8UFD16OAPiRFJfjZN=soAe3WzDBteyvzv-b3CD67jz6Haqyg@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Isoken Ibizugbe","fromEmail":"isokenjune@gmail.com","sentAt":"2023-10-28T10:40:05Z","receivedAt":"2023-10-28T10:41:41Z","isPatch":false,"sender":{"key":"isokenjune@gmail.com","avatar":"https://avatars.githubusercontent.com/u/127752393?v=4"},"body":"On Sat, Oct 28, 2023 at 9:07 AM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> On Wed, Oct 25, 2023 at 2:46 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:\n>\n> > Thank you for the review. I have made changes to the project plan and\n> > it emphasizes the critical tasks of identifying, selecting, and\n> > porting tests, making it more concise and aligned with the project's\n> > scope.\n>\n> Good.\n>\n> > - Community Bonding (Oct 2 - Nov 20): Microproject contribution, Git\n> > project application, get familiar with the Git codebase and testing\n> > ecosystem.\n> > -Identify and Select Tests: Identify and prioritize tests worth\n> > porting, and document the selected tests. (I would classify tests that\n> > are worth porting according to the following for now;\n> >\n> > Relevance: Prioritize tests that are relevant to the current Git codebase.\n> > Coverage: Focus on tests that cover core functionality or critical code paths.\n> > Usage Frequency: Port tests that are frequently used or run in Git's\n> > development process.\n> > Isolation: Choose tests that can be easily ported and run independently.\n>\n> I think the main issue with identification is that now in t/helper/ we\n> have both:\n>\n>   1) code that implements helpers that are used by the end-to-end\n> tests scripts written in shell and named \"t/tXXXX-*.sh\" where XXXX is\n> a number, and\n>   2) code that implements unit tests for some C code in the code base.\n>\n> So I think only 2) should be ported to the unit test framework, and 1)\n> should not be ported and stay in t/helper/.\n>\n> > - Write Unit Tests: Write unit tests for the identified test cases\n> > using the Git custom test framework.\n> > - Port Existing Tests: Port selected test cases from the t/helper\n> > directory to the unit testing framework, by modifying them to work\n> > within the custom TAP framework.\n> > - Test Execution and Debugging: Execute the newly written unit tests\n> > and the ported tests using the test framework.\n> > - Seek Feedback: Share the progress with mentors and the Git\n> > community, and address any concerns or suggestions provided by the\n> > community.\n> > - Documentation and Reporting: Document the entire process of\n> > migrating Git's tests to the unit testing framework, and prepare a\n> > final project report summarizing the work done, challenges faced, and\n> > lessons learned.\n> >\n> > What is the custom TAP framework?\n> >\n> > According to this patch\n> > (https://lore.kernel.org/git/ca284c575ece0aee7149641d5fb1977ccd7e7873.1692229626.git.steadmon@google.com/)\n> > by Phillip Wood, which contains an example implementation for writing\n> > unit tests with TAP output. The custom TAP framework is a Test\n> > Anything Protocol (TAP) framework that allows for clear reporting of\n> > test results, aiding in debugging and troubleshooting.\n>\n> Ok. Our end-to-end tests scripts written in shell already use TAP,\n> that's why it's nice to have unit tests also using TAP.\n>\n> > The framework contains the following features:\n> >\n> > - Test Structure: Unit tests are defined as functions containing\n> > multiple checks. The tests are run using the TEST() macro. If any\n> > checks within a test fail, the entire test is marked as failed.\n> > - Output Format: The output of the test program follows the TAP\n> > format. It includes a series of messages describing the test's status.\n> > For passed tests, it reports \"ok,\" and for failed tests, it reports\n> > \"not ok.\" Each test is numbered, e.g., \"ok 1 - static initialization\n> > works,\" to indicate success or failure.\n> > - Check Functions: Several check functions are available, including\n> > check() for boolean conditions, check_int(), check_uint(), and\n> > check_char() for comparing values using various operators. check_str()\n> > is used to compare strings.\n> > - Skipping Tests: Tests can be skipped using test_skip() and can\n> > include a reason for skipping, which is printed as part of the report.\n> > - Diagnostic Messages: Tests can generate diagnostic messages using\n> > test_msg() to provide additional context or explanations for test\n> > failures.\n> > - Planned Failing Tests: Tests that are known to fail can be marked\n> > with TEST_TODO(). These tests will still run, and the failures will be\n> > reported, but they will not cause the entire suite to fail.\n> > - Building and Running: The unit tests can be built with \"make\n> > unit-tests\" (with some additional Makefile changes), and they can be\n> > executed manually or using a tool like prove.\n>\n> Ok.\n>\n> > Using the formerly given criteria, test-ctype.c is suitable for\n> > porting because it tests character type checks used extensively in\n> > Git. These tests cover various character types and their expected\n> > behaviour, ensuring the correctness and reliability of Git's\n> > operations, and test-ctype.c isolation makes it suitable for porting\n> > without relying on multiple libraries.\n>\n> Ok.\n>\n> > Here is a sample of the implementation of how I would write the unit\n> > test following the custom TAP framework taking t/helper/test-ctype.c\n> >\n> > - Create and rename the new .c file;\n> > I would rename it according to the convention done in the t/unit-test\n> > directory, by starting the name with a “t-” prefix e.g t-ctype.c\n> >\n> > - Document the tests and include the necessary headers:\n> > /**\n> >  *Tests the behavior of ctype\n> >  *functions\n> > */\n> > #include \"test-lib.h\"\n> > #include \"ctype.h\"\n> >\n> > - Define test functions:\n> > #define DIGIT \"0123456789\"\n> >\n> > static void t_digit_type(void)\n> > {\n> >     int i;\n> >     const char *digits = DIGIT;\n> >     for (i = 0; digits[i]; i++)\n> >    {\n> >          check_int(isdigit(digits[i]), ==, 0);\n> >    }\n>\n> This tests that isdigit() returns 0 for each of the characters in\n> \"0123456789\", but first I think isdigit() should return 1, not 0 for\n> those characters.\n\nyes, that is true. should I send a re-roll?\n>\n> And second, I think the test should check the value returned by\n> isdigit() for each of the 256 possible values of a char, not just for\n> the characters in \"0123456789\".\n>\n> test-ctype.c is doing the right thing regarding those 2 issues.\n>\n> > - Include main function which will call the test functions using the TEST macro;\n> > int main(void)\n> > {\n> >     TEST(t_digit_type(), \"Character is a digit\");\n> >     return test_done();\n> > }\n> >\n> > - Run the tests:\n> > ‘make && make’ unit-tests can be used build and run the unit tests\n> > Or run the test binaries directly:\n> > ./t/unit-tests/t-ctype.c\n> >\n> > The Makefile will be modified to add the file;\n> > UNIT_TEST_PROGRAMS += t-ctype\n> > The test output will be in the TAP format and will indicate which\n> > tests passed(ok) and which failed(not ok), along with diagnostic\n> > messages in case of failures.\n> >\n> > ok 1 - Character is a digit\n> >\n> > 1..1\n>\n> Yeah, this looks right.\n>\n> Thanks,\n> Christian.\n"},{"id":"484027","messageId":"CAP8UFD1+aWGymjssk5CotPjEmhu5sMcTy-b7eJc4fw-UA41Qig@mail.gmail.com","threadId":"60399","inReplyTo":"CAJHH8bGK28Fc+VG3uxgC5sGgFEAw6_6AEtusgmw7c4Vz0iGF_g@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-10-28T12:37:47Z","receivedAt":"2023-10-28T12:38:02Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Oct 28, 2023 at 12:41 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:\n>\n> On Sat, Oct 28, 2023 at 9:07 AM Christian Couder\n> <christian.couder@gmail.com> wrote:\n\n> > > #define DIGIT \"0123456789\"\n> > >\n> > > static void t_digit_type(void)\n> > > {\n> > >     int i;\n> > >     const char *digits = DIGIT;\n> > >     for (i = 0; digits[i]; i++)\n> > >    {\n> > >          check_int(isdigit(digits[i]), ==, 0);\n> > >    }\n> >\n> > This tests that isdigit() returns 0 for each of the characters in\n> > \"0123456789\", but first I think isdigit() should return 1, not 0 for\n> > those characters.\n>\n> yes, that is true. should I send a re-roll?\n\nYes, please.\n"},{"id":"484029","messageId":"CAJHH8bHCfx3vknPCGATbLZeTA7hYrVVtnYqfE1avWkiL1PvU1g@mail.gmail.com","threadId":"60399","inReplyTo":"CAP8UFD1+aWGymjssk5CotPjEmhu5sMcTy-b7eJc4fw-UA41Qig@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Isoken Ibizugbe","fromEmail":"isokenjune@gmail.com","sentAt":"2023-10-28T14:07:58Z","receivedAt":"2023-10-28T14:09:31Z","isPatch":false,"sender":{"key":"isokenjune@gmail.com","avatar":"https://avatars.githubusercontent.com/u/127752393?v=4"},"body":"On Sat, Oct 28, 2023 at 1:38 PM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> On Sat, Oct 28, 2023 at 12:41 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:\n> >\n> > On Sat, Oct 28, 2023 at 9:07 AM Christian Couder\n> > <christian.couder@gmail.com> wrote:\n>\n> > > > #define DIGIT \"0123456789\"\n> > > >\n> > > > static void t_digit_type(void)\n> > > > {\n> > > >     int i;\n> > > >     const char *digits = DIGIT;\n> > > >     for (i = 0; digits[i]; i++)\n> > > >    {\n> > > >          check_int(isdigit(digits[i]), ==, 0);\n> > > >    }\n> > >\n> > > This tests that isdigit() returns 0 for each of the characters in\n> > > \"0123456789\", but first I think isdigit() should return 1, not 0 for\n> > > those characters.\n> >\n> > yes, that is true. should I send a re-roll?\n>\n> Yes, please.\n\n#include \"test-lib.h\"\n#include \"ctype.h\"\n\nstatic void t_digit_type(void)\n{\n    int i;\n\nfor (i = 0; i < 256; i++)\n        {\n            if (i < '0' || i > '9')\n                check_int(isdigit(i), ==, 0);\n            else\n                check_int(isdigit(i), ==, 1);\n        }\n}\n\nint main(void)\n{\n    TEST(t_digit_type(), \"Character is a digit\");\n    return test_done();\n}\n"},{"id":"484050","messageId":"9c317b54-7ed4-4ca6-ad75-6857ded0d658@crinan.ddns.net","threadId":"60399","inReplyTo":"CAJHH8bHCfx3vknPCGATbLZeTA7hYrVVtnYqfE1avWkiL1PvU1g@mail.gmail.com","subject":"Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application","fromName":"Phillip Wood","fromEmail":"phil@crinan.ddns.net","sentAt":"2023-10-29T14:43:33Z","receivedAt":"2023-10-29T14:43:43Z","isPatch":false,"sender":{"key":"phil@crinan.ddns.net","avatar":null},"body":"Hi Isoken\n\nOn 28/10/2023 15:07, Isoken Ibizugbe wrote:\n> #include \"test-lib.h\"\n> #include \"ctype.h\"\n> \n> static void t_digit_type(void)\n> {\n>      int i;\n> \n> for (i = 0; i < 256; i++)\n>          {\n>              if (i < '0' || i > '9')\n>                  check_int(isdigit(i), ==, 0);\n>              else\n>                  check_int(isdigit(i), ==, 1);\n>          }\n> }\n\nI think this is correct but when you are writing tests it is important \nto think about how easy they will be to debug if they fail. In this case \nbecause there is a single test to check all the characters it will be \nhard to tell which character caused the test to fail. If we restructure \nthe code to use a separate test for each character then we will be able \nto see which characters are causing isdigit() to fail. To do that we \nneed a function that prints the character that we're testing. Because we \ndon't want to print raw control characters in the test name we need to \ncheck if the character can be printed as is or if it needs to be printed \nas an octal escape sequence. We can do that by writing a function like\n\nstatic const char* char_name(int i)\n{\n\tstatic char buf[5];\n\tif (i < ' ' || i >= 127)\n\t\txsnprintf(buf, sizeof(buf), \"\\\\%03o\", (unsigned int)i);\n\telse\n\t\txsnprintf(buf, sizeof(buf), \"%c\", i);\n\n\treturn buf;\n}\n\nThen we can write a test function defines a separate test for each character\n\nstatic void t_isdigit(void)\n{\n\tfor (int i = 0; i < 256; i++) {\n\t\tif (i < '0' || i > '9')\n\t\t\tTEST(check(!isdigit(i)), \"'%s' is not a digit\",\n\t\t\t     char_name(i));\n\t\telse\n\t\t\tTEST(check(isdigit(i)), \"'%s' is a digit\",\n\t\t\t     char_name(i));\n\t}\n}\n\nNote that as isdigit() returns a boolean we simplify things by using \ncheck() rather than check_int().\n\nNow we can easily see which character is being tested when a check fails \nas the character being tested is in the test name. You would call this \nfunction with\n\nint cmd_main(int argc, const char** argv)\n{\n\tt_isdigit();\n\treturn test_done();\n}\n\nI think it would be helpful for you to try and build and run this test \nby checking out the unit test branch from Junio's tree[1] and adding \nthis test. You could then try making the test fail to see what the \noutput for a failing test looks like.\n\nBest Wishes\n\nPhillip\n\n[1] You can fetch that branch with\n         git fetch https://github.com/gitster/git.git \njs/doc-unit-tests-with-cmake\n     and then create your branch with\n         git checkout -b isdigit-unit-tests FETCH_HEAD\n"}]}