[Outreachy][proposal]: Finish Adding an os-version Capability to Git Protocol v2

>
> Hello Git Community,
> I hope you are doing well.
>
> ## Introduction:
> My name is Abraham Samuel, I am participating in the December 2024
> Outreachy internship program and
> this is my proposal for the project "Finish adding os-version
> capability to Git protocol v2".
>
> ## Contribution to the Git Community:
>
> I have participated in contributions to Git’s codebase after getting
> accepted into the contribution phase in October 2024, working on what
> I found doable and within my reach. Below is the list of my
> contributions:
>
> - [PATCH v4] t7300-clean.sh: use test_path* helper functions for error logging.
>
>        List thread:
> https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@gmail.com/
>
>        Status: merged into master
>
>        Merge Commit: 77af53f56f100b49fdcf294f687b36064d16feca
>
>        Description: The patch converted instances of  “test - [def]”
> in test cases to test_path_* functions to get error logs when the test
> case fails when testing for the existence of a file or directory after
> “git clean” or “git clean -d” is called as the case may be.
>
>
>
> - [PATCH v4] notes: teach the -e option to edit messages in the editor
>
>        Status: integrated into Seen

>        List thread:
> https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@gmail.com/
>
>        Description: The patch worked on a #leftover bit which added
> the “-e” option to “git notes add” and “git notes append” subcommands
> when the message is supplied with the -F and/or -m options. The patch
> enables fine-tuning the message by invoking the user’s default editor
> prefilling the message in the editor to allow editing the message to
> the required taste before adding the note to the commit
>
> ## Project Overview:
> This proposal outlines a plan to complete the work on the os-version capability
> patch series for Git's protocol v2. Initially introduced in June 2024,
> this feature intends to enhance
> communication by allowing Git clients and servers to share their
> operating system (OS) information.
> The capability aims to provide metadata that can improve issues
> diagnosis and enable statistical insights.
>
> This project will involve refining the original patch which already
> started the process of adding this feature,
> addressing Windows compatibility issues, and implementing
> configuration options to customise how the OS is
> shared.
>
> ## Intern objectives:
> The key objectives of this project are;
> 1. Finalize 'os-version' Capability: Modify the existing patch series
> to meet community requirements and improve
> functionality, ensuring compatibility with different OS environments.
> 2. Add configuration options: Create options that allow users to:
>     - Share only the OS name by default (eg, "Linux", "Windows")
>     - Disable OS information sharing completely
>     - Include a more verbose OS version display using commands like
> uname -srvm on Linux

> 3. Fix Windows Compatibility: Review and resolve issues with the
> current tests on Windows, ensuring full cross-platform
> support
> 4. Ensure Tests Coverage and Reliability:  Create robust tests to
> verify the feature's functionality across supported platforms,
> incorporating community feedback to refine and improve the patch series.
>
> ## Approach and Methodology
> 1. Analyze and retrieve the existing patch series:
>     - Retrieve patches from the Git mailing list
>     - Review the current code and community feedback to understand
> necessary improvements and privacy concerns
>
> 2. Apply and test the patch on a new branch:
>     - Set up a new branch based on master to isolate the work on the
> os-version feature
>     - Apply the patches and perform an initial round of tests to
> determine specific errors and how to address them
>
> 3. Address Community concerns and implement improvements
>     - Implement feedback on sending only the OS name (eg, "Windows")by
> default using uname or equivalent method on different OSes
>     - Add configuration options for users to adjust the level of
> detail in OS information sharing
>     - Allow toggling the feature off for privacy or preference
>     - Ensure that configuration changes are well-documented and user-friendly
>
> 4. Resolve Windows Compatibility issues:
>     - Address current test failures on Windows, working closely with
> community inputs to meet compatibility standards
>     - Modify any OS-specific code or test as needed, to work across environments
>
> 5. Develop and refine tests:
>     - Ensure the test case covers all functionality: OS name  sharing,
> version details and disabled state
>     - Conduct platform-specific tests on Linux, Windows and other
> environments to confirm accuracy

>     - Incorporate feedback from mentors and the community to finalize
> the feature's functionality and robustness.
>
> 6. Document the feature and prepare for submission:
>     - Write documentation and examples for configuring the os-version
> capability, explaining options and use cases
>     - Prepare the final patch series, following Git's contribution
> guidelines for submission to the Git mailing list
>
> ## Timeline
> 1. Community Onboarding: (Week 1 -2):
>     Tasks:
>         - Retrieve patches and create a dedicated branch
>         - Study past discussions and understand the improvements required
>         - Set up blog post to write about internship experience
> 2. Initial Testing and Patching (Week 3 - 4):
>     Tasks:
>         - Apply Patches
>         - Run Initial tests
>         - Identify current issues, especially Windows compatibility
> 3. Implement OS version configuration option (Week 5 - 7):
>     Tasks:
>         - Add options for OS name, detailed OS version and disabled state
>         - submit the initial patch series to the Git mailing list for review
> 4. Windows Compatibility (Week 8 - 9):
>     Tasks:
>         - Review, debug and resolve Windows-specific issues
>         - Perform cross-platform testing and verify functionality
> 5. Test Expansion (Week 9 - 11):
>     Tasks:
>         - Write comprehensive tests for OS version capabilities.
>         - Integrate tests to cover each configuration option.
>         - Submit initial patches for tests to the Git mailing list
>        - Implement community feedback and reviews on submitted test patches
> 6. Finalizing and Documentation:( Week 12 - 14):
>     Tasks:
>        - Finalize code based on community inputs
>        - Prepare final patch patch submission with full documentation
>       - Complete my blog on internship experience
>
> ## Availability:
> I will be available to work for a minimum of 30 hours per week and I
> am not currently
> enrolled in any academic activities or have any jobs.
>
> ## Post Outreachy:
> The Git community fosters proper and effective communication,
> regardless of one’s level of experience. The patience, guidance and
> explanation of technical concepts shown by community members are
> wonderful and this has made me grow not just technically but also
> behaviorally. Due to this, I plan to continue actively participating
> the in Git community and be part next generation of those saddled with

> sustaining this great project and preserving its legacy.
>
> ## Appreciation:
>  A special appreciation to everyone on the mailing list for reviewing
> my patches, the mentorship and guidance
> I am grateful to you all.

>
> Hi Samuel,
>
>
> On Mon, Oct 28, 2024 at 9:07 AM Samuel Abraham
> <abrahamadekunle50@gmail.com> wrote:
> >
> > Hello Git Community,
> > I hope you are doing well.
> >
> > ## Introduction:
> > My name is Abraham Samuel, I am participating in the December 2024
> > Outreachy internship program and
> > this is my proposal for the project "Finish adding os-version
> > capability to Git protocol v2".
> >
> > ## Contribution to the Git Community:
> >
> > I have participated in contributions to Git’s codebase after getting
> > accepted into the contribution phase in October 2024, working on what
> > I found doable and within my reach. Below is the list of my
> > contributions:
> >
> > - [PATCH v4] t7300-clean.sh: use test_path* helper functions for error logging.
> >
> >        List thread:
> > https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@gmail.com/
> >
> >        Status: merged into master
> >
> >        Merge Commit: 77af53f56f100b49fdcf294f687b36064d16feca
> >
> >        Description: The patch converted instances of  “test - [def]”
> > in test cases to test_path_* functions to get error logs when the test
> > case fails when testing for the existence of a file or directory after
> > “git clean” or “git clean -d” is called as the case may be.
> >
> >
> >
> > - [PATCH v4] notes: teach the -e option to edit messages in the editor
> >
> >        Status: integrated into Seen
>
> It looks like it has even been merged into 'next' and its status in
> the last "What's cooking in git.git ..." email is "Will merge to
> master?"
>
> It would be nice to give the branch name "sa/notes-edit" to make the
> topic easier to track.

>
> >        List thread:
> > https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@gmail.com/
> >
> >        Description: The patch worked on a #leftover bit which added
> > the “-e” option to “git notes add” and “git notes append” subcommands
> > when the message is supplied with the -F and/or -m options. The patch
> > enables fine-tuning the message by invoking the user’s default editor
> > prefilling the message in the editor to allow editing the message to
> > the required taste before adding the note to the commit
> >
> > ## Project Overview:
> > This proposal outlines a plan to complete the work on the os-version capability
> > patch series for Git's protocol v2. Initially introduced in June 2024,
> > this feature intends to enhance
> > communication by allowing Git clients and servers to share their
> > operating system (OS) information.
> > The capability aims to provide metadata that can improve issues
> > diagnosis and enable statistical insights.
> >
> > This project will involve refining the original patch which already
> > started the process of adding this feature,
> > addressing Windows compatibility issues, and implementing
> > configuration options to customise how the OS is
> > shared.
> >
> > ## Intern objectives:
> > The key objectives of this project are;
> > 1. Finalize 'os-version' Capability: Modify the existing patch series
> > to meet community requirements and improve
> > functionality, ensuring compatibility with different OS environments.
> > 2. Add configuration options: Create options that allow users to:
> >     - Share only the OS name by default (eg, "Linux", "Windows")
> >     - Disable OS information sharing completely
> >     - Include a more verbose OS version display using commands like
> > uname -srvm on Linux
>
> Making it possible to customize what is shared, for example something
> like "OS: Linux, Arch: x86_64" might be nice too.
>

> > 3. Fix Windows Compatibility: Review and resolve issues with the
> > current tests on Windows, ensuring full cross-platform
> > support
> > 4. Ensure Tests Coverage and Reliability:  Create robust tests to
> > verify the feature's functionality across supported platforms,
> > incorporating community feedback to refine and improve the patch series.
> >
> > ## Approach and Methodology
> > 1. Analyze and retrieve the existing patch series:
> >     - Retrieve patches from the Git mailing list
> >     - Review the current code and community feedback to understand
> > necessary improvements and privacy concerns
> >
> > 2. Apply and test the patch on a new branch:
> >     - Set up a new branch based on master to isolate the work on the
> > os-version feature
> >     - Apply the patches and perform an initial round of tests to
> > determine specific errors and how to address them
> >
> > 3. Address Community concerns and implement improvements
> >     - Implement feedback on sending only the OS name (eg, "Windows")by
> > default using uname or equivalent method on different OSes
> >     - Add configuration options for users to adjust the level of
> > detail in OS information sharing
> >     - Allow toggling the feature off for privacy or preference
> >     - Ensure that configuration changes are well-documented and user-friendly
> >
> > 4. Resolve Windows Compatibility issues:
> >     - Address current test failures on Windows, working closely with
> > community inputs to meet compatibility standards
> >     - Modify any OS-specific code or test as needed, to work across environments
> >
> > 5. Develop and refine tests:
> >     - Ensure the test case covers all functionality: OS name  sharing,
> > version details and disabled state
> >     - Conduct platform-specific tests on Linux, Windows and other
> > environments to confirm accuracy
>
> It might be nice to explain how you plan to test on different platforms.
>

> >     - Incorporate feedback from mentors and the community to finalize
> > the feature's functionality and robustness.
> >
> > 6. Document the feature and prepare for submission:
> >     - Write documentation and examples for configuring the os-version
> > capability, explaining options and use cases
> >     - Prepare the final patch series, following Git's contribution
> > guidelines for submission to the Git mailing list
> >
> > ## Timeline
> > 1. Community Onboarding: (Week 1 -2):
> >     Tasks:
> >         - Retrieve patches and create a dedicated branch
> >         - Study past discussions and understand the improvements required
> >         - Set up blog post to write about internship experience
> > 2. Initial Testing and Patching (Week 3 - 4):
> >     Tasks:
> >         - Apply Patches
> >         - Run Initial tests
> >         - Identify current issues, especially Windows compatibility
> > 3. Implement OS version configuration option (Week 5 - 7):
> >     Tasks:
> >         - Add options for OS name, detailed OS version and disabled state
> >         - submit the initial patch series to the Git mailing list for review
> > 4. Windows Compatibility (Week 8 - 9):
> >     Tasks:
> >         - Review, debug and resolve Windows-specific issues
> >         - Perform cross-platform testing and verify functionality
> > 5. Test Expansion (Week 9 - 11):
> >     Tasks:
> >         - Write comprehensive tests for OS version capabilities.
> >         - Integrate tests to cover each configuration option.
> >         - Submit initial patches for tests to the Git mailing list
> >        - Implement community feedback and reviews on submitted test patches
> > 6. Finalizing and Documentation:( Week 12 - 14):
> >     Tasks:
> >        - Finalize code based on community inputs
> >        - Prepare final patch patch submission with full documentation
> >       - Complete my blog on internship experience
> >
> > ## Availability:
> > I will be available to work for a minimum of 30 hours per week and I
> > am not currently
> > enrolled in any academic activities or have any jobs.
> >
> > ## Post Outreachy:
> > The Git community fosters proper and effective communication,
> > regardless of one’s level of experience. The patience, guidance and
> > explanation of technical concepts shown by community members are
> > wonderful and this has made me grow not just technically but also
> > behaviorally. Due to this, I plan to continue actively participating
> > the in Git community and be part next generation of those saddled with
>
> Nit: maybe s/part next/part of the next/

>
> > sustaining this great project and preserving its legacy.
> >
> > ## Appreciation:
> >  A special appreciation to everyone on the mailing list for reviewing
> > my patches, the mentorship and guidance
> > I am grateful to you all.
>
> Thanks,
> Christian.

>
> On Tue, Oct 29, 2024 at 8:19 AM Christian Couder
> <christian.couder@gmail.com> wrote:
> >
> > Hi Samuel,
> >
> >
> > On Mon, Oct 28, 2024 at 9:07 AM Samuel Abraham
> > <abrahamadekunle50@gmail.com> wrote:
> > >
> > > Hello Git Community,
> > > I hope you are doing well.
> > >
> > > ## Introduction:
> > > My name is Abraham Samuel, I am participating in the December 2024
> > > Outreachy internship program and
> > > this is my proposal for the project "Finish adding os-version
> > > capability to Git protocol v2".
> > >
> > > ## Contribution to the Git Community:
> > >
> > > I have participated in contributions to Git’s codebase after getting
> > > accepted into the contribution phase in October 2024, working on what
> > > I found doable and within my reach. Below is the list of my
> > > contributions:
> > >
> > > - [PATCH v4] t7300-clean.sh: use test_path* helper functions for error logging.
> > >
> > >        List thread:
> > > https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@gmail.com/
> > >
> > >        Status: merged into master
> > >
> > >        Merge Commit: 77af53f56f100b49fdcf294f687b36064d16feca
> > >
> > >        Description: The patch converted instances of  “test - [def]”
> > > in test cases to test_path_* functions to get error logs when the test
> > > case fails when testing for the existence of a file or directory after
> > > “git clean” or “git clean -d” is called as the case may be.
> > >
> > >
> > >
> > > - [PATCH v4] notes: teach the -e option to edit messages in the editor
> > >
> > >        Status: integrated into Seen
> >
> > It looks like it has even been merged into 'next' and its status in
> > the last "What's cooking in git.git ..." email is "Will merge to
> > master?"
> >
> > It would be nice to give the branch name "sa/notes-edit" to make the
> > topic easier to track.
>
> Okay thank you Christian.
> >
> > >        List thread:
> > > https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@gmail.com/
> > >
> > >        Description: The patch worked on a #leftover bit which added
> > > the “-e” option to “git notes add” and “git notes append” subcommands
> > > when the message is supplied with the -F and/or -m options. The patch
> > > enables fine-tuning the message by invoking the user’s default editor
> > > prefilling the message in the editor to allow editing the message to
> > > the required taste before adding the note to the commit
> > >
> > > ## Project Overview:
> > > This proposal outlines a plan to complete the work on the os-version capability
> > > patch series for Git's protocol v2. Initially introduced in June 2024,
> > > this feature intends to enhance
> > > communication by allowing Git clients and servers to share their
> > > operating system (OS) information.
> > > The capability aims to provide metadata that can improve issues
> > > diagnosis and enable statistical insights.
> > >
> > > This project will involve refining the original patch which already
> > > started the process of adding this feature,
> > > addressing Windows compatibility issues, and implementing
> > > configuration options to customise how the OS is
> > > shared.
> > >
> > > ## Intern objectives:
> > > The key objectives of this project are;
> > > 1. Finalize 'os-version' Capability: Modify the existing patch series
> > > to meet community requirements and improve
> > > functionality, ensuring compatibility with different OS environments.
> > > 2. Add configuration options: Create options that allow users to:
> > >     - Share only the OS name by default (eg, "Linux", "Windows")
> > >     - Disable OS information sharing completely
> > >     - Include a more verbose OS version display using commands like
> > > uname -srvm on Linux
> >
> > Making it possible to customize what is shared, for example something
> > like "OS: Linux, Arch: x86_64" might be nice too.
> >
>
> Okay thank you for the insight.
>
> > > 3. Fix Windows Compatibility: Review and resolve issues with the
> > > current tests on Windows, ensuring full cross-platform
> > > support
> > > 4. Ensure Tests Coverage and Reliability:  Create robust tests to
> > > verify the feature's functionality across supported platforms,
> > > incorporating community feedback to refine and improve the patch series.
> > >
> > > ## Approach and Methodology
> > > 1. Analyze and retrieve the existing patch series:
> > >     - Retrieve patches from the Git mailing list
> > >     - Review the current code and community feedback to understand
> > > necessary improvements and privacy concerns
> > >
> > > 2. Apply and test the patch on a new branch:
> > >     - Set up a new branch based on master to isolate the work on the
> > > os-version feature
> > >     - Apply the patches and perform an initial round of tests to
> > > determine specific errors and how to address them
> > >
> > > 3. Address Community concerns and implement improvements
> > >     - Implement feedback on sending only the OS name (eg, "Windows")by
> > > default using uname or equivalent method on different OSes
> > >     - Add configuration options for users to adjust the level of
> > > detail in OS information sharing
> > >     - Allow toggling the feature off for privacy or preference
> > >     - Ensure that configuration changes are well-documented and user-friendly
> > >
> > > 4. Resolve Windows Compatibility issues:
> > >     - Address current test failures on Windows, working closely with
> > > community inputs to meet compatibility standards
> > >     - Modify any OS-specific code or test as needed, to work across environments
> > >
> > > 5. Develop and refine tests:
> > >     - Ensure the test case covers all functionality: OS name  sharing,
> > > version details and disabled state
> > >     - Conduct platform-specific tests on Linux, Windows and other
> > > environments to confirm accuracy
> >
> > It might be nice to explain how you plan to test on different platforms.
> >
>
> Okay I will dot that.
> > >     - Incorporate feedback from mentors and the community to finalize
> > > the feature's functionality and robustness.
> > >
> > > 6. Document the feature and prepare for submission:
> > >     - Write documentation and examples for configuring the os-version
> > > capability, explaining options and use cases
> > >     - Prepare the final patch series, following Git's contribution
> > > guidelines for submission to the Git mailing list
> > >
> > > ## Timeline
> > > 1. Community Onboarding: (Week 1 -2):
> > >     Tasks:
> > >         - Retrieve patches and create a dedicated branch
> > >         - Study past discussions and understand the improvements required
> > >         - Set up blog post to write about internship experience
> > > 2. Initial Testing and Patching (Week 3 - 4):
> > >     Tasks:
> > >         - Apply Patches
> > >         - Run Initial tests
> > >         - Identify current issues, especially Windows compatibility
> > > 3. Implement OS version configuration option (Week 5 - 7):
> > >     Tasks:
> > >         - Add options for OS name, detailed OS version and disabled state
> > >         - submit the initial patch series to the Git mailing list for review
> > > 4. Windows Compatibility (Week 8 - 9):
> > >     Tasks:
> > >         - Review, debug and resolve Windows-specific issues
> > >         - Perform cross-platform testing and verify functionality
> > > 5. Test Expansion (Week 9 - 11):
> > >     Tasks:
> > >         - Write comprehensive tests for OS version capabilities.
> > >         - Integrate tests to cover each configuration option.
> > >         - Submit initial patches for tests to the Git mailing list
> > >        - Implement community feedback and reviews on submitted test patches
> > > 6. Finalizing and Documentation:( Week 12 - 14):
> > >     Tasks:
> > >        - Finalize code based on community inputs
> > >        - Prepare final patch patch submission with full documentation
> > >       - Complete my blog on internship experience
> > >
> > > ## Availability:
> > > I will be available to work for a minimum of 30 hours per week and I
> > > am not currently
> > > enrolled in any academic activities or have any jobs.
> > >
> > > ## Post Outreachy:
> > > The Git community fosters proper and effective communication,
> > > regardless of one’s level of experience. The patience, guidance and
> > > explanation of technical concepts shown by community members are
> > > wonderful and this has made me grow not just technically but also
> > > behaviorally. Due to this, I plan to continue actively participating
> > > the in Git community and be part next generation of those saddled with
> >
> > Nit: maybe s/part next/part of the next/
>
> Noted.
> >
> > > sustaining this great project and preserving its legacy.
> > >
> > > ## Appreciation:
> > >  A special appreciation to everyone on the mailing list for reviewing
> > > my patches, the mentorship and guidance
> > > I am grateful to you all.
> >
> > Thanks,
> > Christian.