Git development
 help / color / mirror / Atom feed
From: kerylefondji7@gmail.com
To: git@vger.kernel.org
Cc: gitster@pobox.com, phillip.wood123@gmail.com,
	christian.couder@gmail.com, siddharthasthana31@gmail.com
Subject: [OUTREACHY][PROPOSAL] Improve how command arguments and options are scanned and parsed - Keryle Fondji
Date: Wed,  4 Nov 2026 15:37:41 +0100	[thread overview]
Message-ID: <20261104143741.654-1-kerylefondji7@gmail.com> (raw)

Hi mentors and the Git community,

Here is my Outreachy proposal for the project "Improve how command
arguments and options are scanned and parsed".

I would appreciate any feedback from mentors and the community.

Personal Information
--------------------

Full Name: Fondji Tamekong Keryle Blondeau
Email Address: kerylefondji7@gmail.com
Location: Kribi, Cameroon (WAT, UTC+1)

About me
--------

I am a self-taught C developer with a background in computer science,
interested in low-level programming and open-source development.

My journey into open source began when a friend introduced me to open
source and shared details about Outreachy.

When I first tried to apply to Git years ago, I struggled with the
codebase and could not finish a patch in time. However, I remained
motivated to learn. I spent time studying Git internals and improving
my C programming skills.

Returning to Outreachy this year with better preparation, I was able
to follow the mailing list workflow and complete a merged contribution.
Working on Git's parse-options API confirmed that the "Improve how
command arguments and options are scanned and parsed" project is the
right fit for my 13-week internship.

Project Details
===============
Applicant: Fondji Tamekong Keryle Blondeau
Mentors: Christian Couder, Siddharth Asthana

Contributions Summary
====================

Contribution #1: started Oct. 17, 2026. Not accepted or merged.

Patch: [PATCH v3] builtin/var: refactor to use parse-options API [1]

Details:
On October 17, 2026, I started working on converting option handling in
builtin/var.c to the parse-options API. I sent three patch revisions
(up to v3), updating the option structures, flag logic, and formatting.

Context, Learnings & Outcome:
During code review, Phillip Wood explained that git var had already been
converted in commit e19f0779c67 in September 2026 [1]. Even though the
changes were already upstreamed, this attempt was very helpful. Phillip
noted that the main goal of microprojects is to help candidates practice
sending patches, using the mailing list, and handling reviews.
Through his response, I learned how to run the test suite, search the
mailing list archives [6], check the 'seen' branch, and use microproject
documentation [4, 5].


Contribution #2: started Oct. 26, 2026. Accepted and merged into 'next'
(marked "Will merge to 'master'").

Patch: [PATCH v7] archive-zip: refactor 'path too long' error message
to use Q_() [2]

Details:
On October 26, 2026, I started working on the error message in
archive-zip.c for pathnames that exceed maximum length limits. I updated
the code to replace _() with Q_() to handle plural forms correctly for
internationalization [2].

Context, Learnings & Outcome:
I submitted seven patch revisions (v1 to v7) on the mailing list [2].
Thanks to clear feedback from Junio C. Hamano, Phillip Wood, and
Kristoffer Haugsbakk, I gained practical experience in:
- Internationalization (i18n): Using Q_() to handle plural forms across
  different languages.
- Git Coding Guidelines: Following indentation standards, aligning
  function arguments, keeping lines under 80 characters, and using tabs.
- Patch Workflow: Structuring commit messages according to
  SubmittingPatches.

On October 29, 2026, patch v7 was accepted and merged into 'next'
(commit ae25f6f799), and included in Junio C. Hamano's "What's cooking
in git.git" report marked as "Will merge to 'master'" [3].


Availability
============
I am committed to 40 hours per week during the internship.
I am based in Kribi, Cameroon (WAT, UTC+1) and can adjust my hours for
calls, syncs, and reviews.
I have no conflicting work or exam commitments.


Internship Blogging
==================
I will publish regular updates about my progress, technical notes, and
challenges on a schedule agreed with my mentors, and share post links on
the mailing list.

Proposed Timeline
=================

Pre-Internship Period (Now – Dec 6):
- Continue studying the Git codebase and internal option parsing APIs.
- Work on another microproject or cleanup patch on the mailing list to
  keep practicing the patch workflow.
- Discuss initial target builtin/ commands with Christian Couder,
  Siddharth Asthana, Phillip Wood, and Junio C. Hamano.

Weeks 1–2 (Dec 7 – Dec 20): Onboarding & Command Selection
- Set up local test setups for target commands.
- Confirm the first group of builtin/ commands needing option parsing
  refactoring with my mentors.
- Submit a first setup or documentation patch for the workflow.

Weeks 3–6 (Dec 21 – Jan 17): Option Parsing Conversion (Batch 1)
- Convert legacy option parsing in the first set of builtin/ commands to
  the parse-options API.
- Update or add tests in t/ to maintain test coverage.
- Send patch series to the mailing list and address review comments.

Weeks 7–10 (Jan 18 – Feb 14): Refactoring & Cleanup (Batch 2)
- Work on the second set of commands assigned by mentors, including
  subcommands and complex flags.
- Update error messages according to Git coding and internationalization
  standards (Q_() / _()).
- Follow up on review discussions on the mailing list.

Weeks 11–12 (Feb 15 – Feb 28): Testing & Integration
- Prepare final patch revisions based on maintainer and reviewer
  feedback.
- Run full test suite checks on all modified commands to ensure
  stability.

Week 13 (Mar 1 – Mar 8): Documentation & Final Evaluation
- Complete documentation updates and submit the final Outreachy report.
- Outline post-internship contribution goals for Git.

After the Internship
====================
After the internship, I plan to stay active in the Git community by
sending patches, reviewing code, and supporting new contributors.

Appreciation
============
Having my first contribution merged into Git has been a meaningful
achievement for me. I would like to thank Usman Akinyemi for the warm
welcome when I joined the mailing list.

I am very grateful to Junio C. Hamano, Phillip Wood, and Kristoffer
Haugsbakk for their patience, reviews, and guidance on my patch
revisions [1, 2, 3, 4]. Finally, thank you to my mentors, Christian
Couder and Siddharth Asthana, and to the Git community for helping new
contributors learn and progress.

References
==========
[1] https://lore.kernel.org/git/d748915d-c50c-4143-8140-ae885a6ba604@gmail.com/
[2] https://lore.kernel.org/git/20261026192803.1985-2-kerylefondji7@gmail.com/
[3] https://lore.kernel.org/git/xmqqcxsmejd9.fsf@gitster.g/
[4] https://git.github.io/SoC-2026-Microprojects/
[5] https://git.github.io/General-Microproject-Information/
[6] https://lore.kernel.org/git

Best regards,
Fondji Tamekong Keryle Blondeau

                 reply	other threads:[~2026-11-04 14:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261104143741.654-1-kerylefondji7@gmail.com \
    --to=kerylefondji7@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood123@gmail.com \
    --cc=siddharthasthana31@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox