{"thread":{"id":"58728","subject":"[OUTREACHY V3] Unify ref-filter formats with other --pretty formats[proposal]","startedAt":"2022-10-31T20:16:15Z","lastAt":"2022-10-31T20:16:15Z","messageCount":1,"participants":["NSENGIYUMVA WILBERFORCE"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"466112","messageId":"CA+PPyiEnnjeTUCoqddsKDqR2xw8+_gFvQeVJ6wmj_n1JtEUoew@mail.gmail.com","threadId":"58728","inReplyTo":null,"subject":"[OUTREACHY V3] Unify ref-filter formats with other --pretty formats[proposal]","fromName":"NSENGIYUMVA WILBERFORCE","fromEmail":"nsengiyumvawilberforce@gmail.com","sentAt":"2022-10-31T20:15:57Z","receivedAt":"2022-10-31T20:16:15Z","isPatch":false,"sender":{"key":"nsengiyumvawilberforce@gmail.com","avatar":"https://avatars.githubusercontent.com/u/65920105?v=4"},"body":"Hi team,\nThis is the third version of my proposal. I have addressed Hariom's\ncomments and other comments are welcome. I look forward to having a\nfine proposal by Friday. Looking forward to your reviews\n\nGoogle docs version:\nhttps://docs.google.com/document/d/1Kdx8DVWF3c5pwV5-A8Z4n-SoRHlMDncI1gNeGCiLNsE/edit#\n\nName: Nsengiyumva Wilberforce\n\nMajor: Software engineering\n\nMobile no.: +256 785065399\n\nEmail: nsengiyumvawilberforce@gmail.com\n\nIRC: wilber4c\n\nGithub: nsengiyumva-wilberforce\n\nLinkedin: https://www.linkedin.com/in/nsengiyumva-wilberforce-623664192/\n\nTime Zone: EAT (UTC + 03:00)\n\n##About me\n\nI am doing a Bachelor of Science in software engineering at Makerere\nuniversity in my 4th year(final). I spend most of my time writing PHP\napplications. I am also interested in Java and embedded systems\ndevelopment and I have participated in embedded systems development\nprojects like <https://www.ademnea.net/>.\n\n##Microproject\nWhen I was browsing the outreachy projects on outreachy website, I was\nsuper excited about Git because I use it in most of my college work.\nAt first, it was intimidating for me to introduce myself to the\ncommunity. But I am glad I took a step. I am glad that I completed my\nmicroproject and the whole process gave me confidence on how to submit\npatches, communicate with the community members and interestingly, it\nwas a big learning process for me.  The following are the details\nabout my microproject with public-inbox links to different versions.\n\nMailing List for the microproject:\n<https://public-inbox.org/git/pull.1362.v4.git.git.1665772130030.gitgitgadget@gmail.com/>\n\nGithub:  <https://github.com/git/git/pull/1362>\n\nStatus: master\n\n\n##Review on a tiny Git project\nWhile preparing my proposal and making some corrections suggested by\nmy mentors, another outreachy applicant came in. She first had trouble\nwith submitting her patch and I immediately intervened to help. She\nwas having difficulties with an incorrect commit author name and I\nadvised her to set it\nlocally<https://github.com/git/git/pull/1372#issuecomment-1294407743>.\nThis advice helped the applicant solve the problem and she was able to\nsubmit her patch. It was so interesting and I believe I will help more\nnew people.\n\n\n##Proposed Project\n\n##Abstract\nGit has an old problem of duplicated implementations of some logic.\nFor example, Git had at least 4 different implementations to format\ncommand output for different commands. The foremost aim of this\nproject is to simplify codebase by getting rid of duplication of a\nsimilar logic and, as a result, simplify adding new functionality.\nThe current task is to reuse ref-filter formatting logic to minimize\ncode duplication and to have one unified interface to extract all\nneeded data from the object and to print it properly.\n\n##Previous Work\nJayDeep Das(GSoC) tried to “add a new atom ‘signature’”. However, I\nhave not been able to find his complete work in the public box, it\nseems his work was not complete. According to\n<https://github.com/JDeepD/git-1/commit/85ddfa4b33f2b6f05524e648e7165c722188093e>\nwhich was suggested at the outreachy website, it looks like he did not\ncomplete writing the tests for the signature atom he was unifying.\n\nJayDeep’s tests were not able to know if the signature is bad or good,\nso he was supposed to add two tests one to handle good signature and\nanother to handle bad signature like this\n\ntest_expect_success 'test signature atom with grade option and good signature' '\n\ngit verify-commit signed 2>out &&\n\ngrep \"Good signature from\" out &&\n\necho \"G\" >expected &&\n\ngit for-each-ref refs/heads/signed --format=\"%(signature:grade)\" >actual &&\n\ntest_cmp actual expected\n\n'\n\n\ntest_expect_success 'test signature atom with grade option and bad signature' '\n\ngit verify-commit master 2>out &&\n\n! grep \"Good signature from\" out &&\n\necho \"B\" >expected &&\n\ngit for-each-ref refs/heads/signed --format=\"%(signature:grade)\" >actual &&\n\ntest_cmp actual expected\n\n'\n\n##What’s up with the signature atom?\nHariom says in his final report that the signature\natom<https://github.com/harry-hov/git/commits/cc-signature2> was\nimplemented like the new email\nformats<https://public-inbox.org/git/aeb116c5aaaa23dfefbc7a6f4ac743a6f5a3ade8.1595882588.git.gitgitgadget@gmail.com/>,\nbut he again says that it was supposed to be refactored according to\nJunio’s comment<https://public-inbox.org/git/xmqqzh7jcqv7.fsf@gitster.c.googlers.com/>.\nJDeep addresses this by introducing 2 functions namely:\nsignature_atom_parser() where the comparison happens and\ngrab_signature() where the parsing\nhappens<https://github.com/JDeepD/git-1/commit/85ddfa4b33f2b6f05524e648e7165c722188093e>\nwhich I think was a pretty good idea.He also faced an issue of putting\n2 blank lines between the tests that he wrote yet it’s supposed to be\none according to git’s coding guidelines[Christian’s comment]\n\nHariom Verma contributed(https://harry-hov.github.io/blogs/posts/the-final-report)\ntremendously towards “Unifying ref-filter formats with other --pretty\nformats” during GSoC'20 internship. Hariom finished most of the\nformatting options and this will help me build on his work.  His work\nlooks smart and understandable thus adding on his work will be easy.\nAnd also his blog is very fabulous, it’s a shooting point for me to\nstart understanding the codebase very well.\n\n Hariom mentions in his report that 30 % of the log related tests are\nfailing, he also mentions that the cause of tests failure is because\nof the missing mailmap logic and mbox/email commit format in\n<https://github.com/harry-hov/git/commits/pretty-lib-2.0.2>. Hariom\nalso says the failure might be because\n<https://github.com/harry-hov/git/commits/pretty-lib-2.0.2> does not\nhandle unknown formatting options. I plan to start with his advice\nabout the cause of the failure of these tests. In log-tree.c, these\nfollowing two parts were not tested. I am still understanding more\nabout how this can be handled;\n\nif (opt->use_ref_filter)\n\nref_pretty_print_commit(&ctx, commit, &msgbuf);\n\nelse\n\npretty_print_commit(&ctx, commit, &msgbuf);\n\n\n\nif (opt->show_log_size && !opt->use_ref_filter) {\n\nfprintf(opt->diffopt.file, \"log size %i\\n\", (int)msgbuf.len);\n\ngraph_show_oneline(opt->graph);\n\n}\n\n##Hariom’s Remaining work?\n\n-Branch without new file format-support.{c,h}:\n\nWhy does it exist? Junio\nthinks<https://public-inbox.org/git/xmqqlfid1305.fsf@gitster.c.googlers.com/>\nthere is no point in adding new format-support.{c,h} if we were only\nmaking pretty.{c, h} static functions public\n\n-Branch with new file format-support.{c, h}.\n\nWhy does it exist? Initially, Hariom had\nthought<https://public-inbox.org/git/7a64495f99ec97258687695d41d106e3f946d551.1597687822.git.gitgitgadget@gmail.com/>\nit would be nice to have another pair of files to keep the functions\nthat would be used in pretty.c and ref-filter.c but Junio\nsays<https://public-inbox.org/git/xmqqlfid1305.fsf@gitster.c.googlers.com/>\n\n-Branch with new new signature atom for ref-format\n\nWhy does it exist? This new signature atom had been implemented just\nlike the new email formats were initially\nintroduced<https://public-inbox.org/git/aeb116c5aaaa23dfefbc7a6f4ac743a6f5a3ade8.1595882588.git.gitgitgadget@gmail.com/>,\nbut Junio thinks it should be refactored this\nway<https://public-inbox.org/git/xmqqzh7jcqv7.fsf@gitster.c.googlers.com/>.\n\nZheNing Hu’s <https://public-inbox.org/git/CAOLTT8SxHuH2EbiSwQX6pyJJs5KyVuKx6ZOPxpzWLH+Tbz5F+A@mail.gmail.com/>\n work was mainly in 3 stages namely;\n\nStage 1: Implement `git cat-file –batch` driver in ref-filter.*\nsupport `%(raw)` atom in ref-filter, which can print raw data of the\nobject.\n\nStage 2: refactor `git cat-file –batch` to use reuse the logic of ref-filter\n\nStage 3: Optimize ref-filter performance.\n\n\nOlga<olyatelezhnaya@gmail.com> has done great work in “Unifying Git’s\nformat languages” during Outreachy Round 15 and continued even after\nthat [from 28-09-2017 to 04-04-2019]. Her work is mostly related to\n`cat-file` and `ref-filter`.\n\nShe already did a pretty nice job in preparing ref-filter for more\ngeneral usage of its formatting logic.\n\n##Why is Olga’s and ZheNing Hu’s approach problematic?\n\nChristian Couder\nsays<https://public-inbox.org/git/CAP8UFD2skja6kE+w1vPewueQ2wzEck61wiZMftUyA+q=JZ+SMA@mail.gmail.com/>\nthat their project used ref-filter format in cat-file which was a very\nhard approach due to performance issues.\n\n##The Plan\n\nMy task is to look at how pretty formats are different from ref-filter\nformats. When some format is supported by the pretty formats but not\nby the ref-filter formats, and should prepare some patches to support\nthe ref-filter format. I will basically build on Hariom’s previous\nwork\n\nStep 1:List down all the formats supported by the pretty format but\nare not supported by the ref-filter format e.g\n\nUser formats like %ah, %ch, %d, %D, %(describe[:options]), %S,\n%GG,%G?, %GS, %GK, %GF, %GP, %GT, %gD, %gd, %gn, %gN, %ge, %gE, %gs.\n\nStep 2:Read through different patches related to pretty and ref-filter\nformats submitted by different contributors to get a solid and a\nthorough understanding of the pretty and ref-filter formats.\n\nStep 3:Understand an implementation of one or two pretty formats, and\nthen look at how it was implemented in ref-filter format. This is\ngoing to give me direction to refactor the remaining pretty formats\n\nStep 4(possible approach): Pick one format option at a time and\nconvert it to use ref-filter option format\n\n\n##Estimated Timeline\n\nTasks:Community bonding\n\nTime Period:December 5,2022 - January 2, 2023\n\n-understanding all the logic of pretty.* and ref-filter.*\n\n(what functions are used and how all formatting process is going)\n\n-Working with mentors and identifying the best candidates to be converted first.\n\n-Converting a couple of formatting options to reuse ref-filter\nformatting logic and updating the documentation\n\nPeriod:December 25, 2022\nChristmas celebrations :Join my parents for celebrations\n\nperiod: January 1, 2023\nNew year’s day holiday: Join my parents for celebrations\n\nperiod:January 3 - February 3, 2023\nTask:Coding Phase 1\n-Add on Hariom’s work:Converting more formatting options to reuse\nref-filter formatting logic.\n-Finish his incomplete work\n-Update Documentation.\n-Possibly look at Olga’s work\n\nperiod: January 18, 2023\nMy Birthday: Cake cutting with my  friends\n\nFrom January 6 - January 18, 2023:Semester Exams\n I will be working for a few hours per day and always be available to\nreply to any communication\n\nperiod: February 3 - March 3, 2023\nCoding Phase 2\n-Final touch-ups and bug fixes(if any)\n-Update Documentation\n-Wrapping up.\n\n##Blogging about Git\n\nI do love writing a lot however much I have not taken time to put out\nmy personal opinions and thinking. Being an avid reader, I think it’s\nnow my time to start letting other people read what I write, to let\npeople know what I think, what I am doing with my life. And guess\nwhat, I am super excited to start with Git.\n\nI have created a blog site that I will be using\nhttps://nsengiyumva-wilberforce.github.io/\n\n##Availability\n\nI can easily devote 30-40 hours per week since my college just\nrequires 15 hours per week. I plan even to work more extra hours for\nmy internship tasks when time allows.\n\n##Post Outreachy\n\nApart from being an Outreachy intern, I plan to remain a member of git\ncommunity even after my internship, because I believe there is more to\ndo even after the Outreachy internship\n\nHere are some other things I’d like to do beyond Outreachy\n\n-Mentor other students\n\n-Doing code reviews for other contributors\n\n-May be complete the work that I will have left pending after my internship\n\n-Keep learning from all of you...\n\n##Experience with Open Source\n\nI have little  experience with open source, so I hope to learn a lot\nthrough my internship with Git from you all.\n\n\n##Motivation\n\nGit being a world’s best developer version control system, I feel\noverjoyed that even my little first patch was accepted. The community\nis very welcoming, the people there answer questions very first and\nthis turns everything overwhelming to a simple process\n\n\n##Closing remarks (Optional)\n\nI am a consistent and passionate learner. Even if solving a problem\nmay look tricky to me, I just give it all my 100% time and think of\n1000s of ways to approach it. I know I do not have the required\nexpertise to begin working with a skilled team like Git but I believe\nin learning slowly by slowly until I will make it to the peak.\n\n\nI hope you consider and give me a chance to work with git. It’s a\ngreat hope I have that this opportunity is bringing me closer to my\ndreams. Thanks for your consideration.\n\n\nBest Regards\n\n\nNsengiyumva wilberforce\n"}]}