Hi team, This is the third version of my proposal. I have addressed Hariom's comments and other comments are welcome. I look forward to having a fine proposal by Friday. Looking forward to your reviews Google docs version: https://docs.google.com/document/d/1Kdx8DVWF3c5pwV5-A8Z4n-SoRHlMDncI1gNeGCiLNsE/edit# Name: Nsengiyumva Wilberforce Major: Software engineering Mobile no.: +256 785065399 Email: nsengiyumvawilberforce@xxxxxxxxx IRC: wilber4c Github: nsengiyumva-wilberforce Linkedin: https://www.linkedin.com/in/nsengiyumva-wilberforce-623664192/ Time Zone: EAT (UTC + 03:00) ##About me I am doing a Bachelor of Science in software engineering at Makerere university in my 4th year(final). I spend most of my time writing PHP applications. I am also interested in Java and embedded systems development and I have participated in embedded systems development projects like <https://www.ademnea.net/>. ##Microproject When I was browsing the outreachy projects on outreachy website, I was super excited about Git because I use it in most of my college work. At first, it was intimidating for me to introduce myself to the community. But I am glad I took a step. I am glad that I completed my microproject and the whole process gave me confidence on how to submit patches, communicate with the community members and interestingly, it was a big learning process for me. The following are the details about my microproject with public-inbox links to different versions. Mailing List for the microproject: <https://public-inbox.org/git/pull.1362.v4.git.git.1665772130030.gitgitgadget@xxxxxxxxx/> Github: <https://github.com/git/git/pull/1362> Status: master ##Review on a tiny Git project While preparing my proposal and making some corrections suggested by my mentors, another outreachy applicant came in. She first had trouble with submitting her patch and I immediately intervened to help. She was having difficulties with an incorrect commit author name and I advised her to set it locally<https://github.com/git/git/pull/1372#issuecomment-1294407743>. This advice helped the applicant solve the problem and she was able to submit her patch. It was so interesting and I believe I will help more new people. ##Proposed Project ##Abstract Git has an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. The foremost aim of this project is to simplify codebase by getting rid of duplication of a similar logic and, as a result, simplify adding new functionality. The current task is to reuse ref-filter formatting logic to minimize code duplication and to have one unified interface to extract all needed data from the object and to print it properly. ##Previous Work JayDeep Das(GSoC) tried to “add a new atom ‘signature’”. However, I have not been able to find his complete work in the public box, it seems his work was not complete. According to <https://github.com/JDeepD/git-1/commit/85ddfa4b33f2b6f05524e648e7165c722188093e> which was suggested at the outreachy website, it looks like he did not complete writing the tests for the signature atom he was unifying. JayDeep’s tests were not able to know if the signature is bad or good, so he was supposed to add two tests one to handle good signature and another to handle bad signature like this test_expect_success 'test signature atom with grade option and good signature' ' git verify-commit signed 2>out && grep "Good signature from" out && echo "G" >expected && git for-each-ref refs/heads/signed --format="%(signature:grade)" >actual && test_cmp actual expected ' test_expect_success 'test signature atom with grade option and bad signature' ' git verify-commit master 2>out && ! grep "Good signature from" out && echo "B" >expected && git for-each-ref refs/heads/signed --format="%(signature:grade)" >actual && test_cmp actual expected ' ##What’s up with the signature atom? Hariom says in his final report that the signature atom<https://github.com/harry-hov/git/commits/cc-signature2> was implemented like the new email formats<https://public-inbox.org/git/aeb116c5aaaa23dfefbc7a6f4ac743a6f5a3ade8.1595882588.git.gitgitgadget@xxxxxxxxx/>, but he again says that it was supposed to be refactored according to Junio’s comment<https://public-inbox.org/git/xmqqzh7jcqv7.fsf@xxxxxxxxxxxxxxxxxxxxxx/>. JDeep addresses this by introducing 2 functions namely: signature_atom_parser() where the comparison happens and grab_signature() where the parsing happens<https://github.com/JDeepD/git-1/commit/85ddfa4b33f2b6f05524e648e7165c722188093e> which I think was a pretty good idea.He also faced an issue of putting 2 blank lines between the tests that he wrote yet it’s supposed to be one according to git’s coding guidelines[Christian’s comment] Hariom Verma contributed(https://harry-hov.github.io/blogs/posts/the-final-report) tremendously towards “Unifying ref-filter formats with other --pretty formats” during GSoC'20 internship. Hariom finished most of the formatting options and this will help me build on his work. His work looks smart and understandable thus adding on his work will be easy. And also his blog is very fabulous, it’s a shooting point for me to start understanding the codebase very well. Hariom mentions in his report that 30 % of the log related tests are failing, he also mentions that the cause of tests failure is because of the missing mailmap logic and mbox/email commit format in <https://github.com/harry-hov/git/commits/pretty-lib-2.0.2>. Hariom also says the failure might be because <https://github.com/harry-hov/git/commits/pretty-lib-2.0.2> does not handle unknown formatting options. I plan to start with his advice about the cause of the failure of these tests. In log-tree.c, these following two parts were not tested. I am still understanding more about how this can be handled; if (opt->use_ref_filter) ref_pretty_print_commit(&ctx, commit, &msgbuf); else pretty_print_commit(&ctx, commit, &msgbuf); if (opt->show_log_size && !opt->use_ref_filter) { fprintf(opt->diffopt.file, "log size %i\n", (int)msgbuf.len); graph_show_oneline(opt->graph); } ##Hariom’s Remaining work? -Branch without new file format-support.{c,h}: Why does it exist? Junio thinks<https://public-inbox.org/git/xmqqlfid1305.fsf@xxxxxxxxxxxxxxxxxxxxxx/> there is no point in adding new format-support.{c,h} if we were only making pretty.{c, h} static functions public -Branch with new file format-support.{c, h}. Why does it exist? Initially, Hariom had thought<https://public-inbox.org/git/7a64495f99ec97258687695d41d106e3f946d551.1597687822.git.gitgitgadget@xxxxxxxxx/> it would be nice to have another pair of files to keep the functions that would be used in pretty.c and ref-filter.c but Junio says<https://public-inbox.org/git/xmqqlfid1305.fsf@xxxxxxxxxxxxxxxxxxxxxx/> -Branch with new new signature atom for ref-format Why does it exist? This new signature atom had been implemented just like the new email formats were initially introduced<https://public-inbox.org/git/aeb116c5aaaa23dfefbc7a6f4ac743a6f5a3ade8.1595882588.git.gitgitgadget@xxxxxxxxx/>, but Junio thinks it should be refactored this way<https://public-inbox.org/git/xmqqzh7jcqv7.fsf@xxxxxxxxxxxxxxxxxxxxxx/>. ZheNing Hu’s <https://public-inbox.org/git/CAOLTT8SxHuH2EbiSwQX6pyJJs5KyVuKx6ZOPxpzWLH+Tbz5F+A@xxxxxxxxxxxxxx/> work was mainly in 3 stages namely; Stage 1: Implement `git cat-file –batch` driver in ref-filter.* support `%(raw)` atom in ref-filter, which can print raw data of the object. Stage 2: refactor `git cat-file –batch` to use reuse the logic of ref-filter Stage 3: Optimize ref-filter performance. Olga<olyatelezhnaya@xxxxxxxxx> has done great work in “Unifying Git’s format languages” during Outreachy Round 15 and continued even after that [from 28-09-2017 to 04-04-2019]. Her work is mostly related to `cat-file` and `ref-filter`. She already did a pretty nice job in preparing ref-filter for more general usage of its formatting logic. ##Why is Olga’s and ZheNing Hu’s approach problematic? Christian Couder says<https://public-inbox.org/git/CAP8UFD2skja6kE+w1vPewueQ2wzEck61wiZMftUyA+q=JZ+SMA@xxxxxxxxxxxxxx/> that their project used ref-filter format in cat-file which was a very hard approach due to performance issues. ##The Plan My task is to look at how pretty formats are different from ref-filter formats. When some format is supported by the pretty formats but not by the ref-filter formats, and should prepare some patches to support the ref-filter format. I will basically build on Hariom’s previous work Step 1:List down all the formats supported by the pretty format but are not supported by the ref-filter format e.g User formats like %ah, %ch, %d, %D, %(describe[:options]), %S, %GG,%G?, %GS, %GK, %GF, %GP, %GT, %gD, %gd, %gn, %gN, %ge, %gE, %gs. Step 2:Read through different patches related to pretty and ref-filter formats submitted by different contributors to get a solid and a thorough understanding of the pretty and ref-filter formats. Step 3:Understand an implementation of one or two pretty formats, and then look at how it was implemented in ref-filter format. This is going to give me direction to refactor the remaining pretty formats Step 4(possible approach): Pick one format option at a time and convert it to use ref-filter option format ##Estimated Timeline Tasks:Community bonding Time Period:December 5,2022 - January 2, 2023 -understanding all the logic of pretty.* and ref-filter.* (what functions are used and how all formatting process is going) -Working with mentors and identifying the best candidates to be converted first. -Converting a couple of formatting options to reuse ref-filter formatting logic and updating the documentation Period:December 25, 2022 Christmas celebrations :Join my parents for celebrations period: January 1, 2023 New year’s day holiday: Join my parents for celebrations period:January 3 - February 3, 2023 Task:Coding Phase 1 -Add on Hariom’s work:Converting more formatting options to reuse ref-filter formatting logic. -Finish his incomplete work -Update Documentation. -Possibly look at Olga’s work period: January 18, 2023 My Birthday: Cake cutting with my friends >From January 6 - January 18, 2023:Semester Exams I will be working for a few hours per day and always be available to reply to any communication period: February 3 - March 3, 2023 Coding Phase 2 -Final touch-ups and bug fixes(if any) -Update Documentation -Wrapping up. ##Blogging about Git I do love writing a lot however much I have not taken time to put out my personal opinions and thinking. Being an avid reader, I think it’s now my time to start letting other people read what I write, to let people know what I think, what I am doing with my life. And guess what, I am super excited to start with Git. I have created a blog site that I will be using https://nsengiyumva-wilberforce.github.io/ ##Availability I can easily devote 30-40 hours per week since my college just requires 15 hours per week. I plan even to work more extra hours for my internship tasks when time allows. ##Post Outreachy Apart from being an Outreachy intern, I plan to remain a member of git community even after my internship, because I believe there is more to do even after the Outreachy internship Here are some other things I’d like to do beyond Outreachy -Mentor other students -Doing code reviews for other contributors -May be complete the work that I will have left pending after my internship -Keep learning from all of you... ##Experience with Open Source I have little experience with open source, so I hope to learn a lot through my internship with Git from you all. ##Motivation Git being a world’s best developer version control system, I feel overjoyed that even my little first patch was accepted. The community is very welcoming, the people there answer questions very first and this turns everything overwhelming to a simple process ##Closing remarks (Optional) I am a consistent and passionate learner. Even if solving a problem may look tricky to me, I just give it all my 100% time and think of 1000s of ways to approach it. I know I do not have the required expertise to begin working with a skilled team like Git but I believe in learning slowly by slowly until I will make it to the peak. I hope you consider and give me a chance to work with git. It’s a great hope I have that this opportunity is bringing me closer to my dreams. Thanks for your consideration. Best Regards Nsengiyumva wilberforce
