Hello Christian On Wed, Nov 9, 2022 at 2:49 PM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > Hi, > > On Tue, Nov 8, 2022 at 11:55 AM Debra Obondo <debraobondo@xxxxxxxxx> wrote: > > > > Hello Team, > > This is a draft proposal for the Outreachy Internship, could I kindly > > have your reviews on it. > > https://docs.google.com/document/d/11HX9dkEH--ZfXBTRWJ8rhGnlf3Bj_n_4U2Z-qgbDYVM/edit?usp=sharing > > I am going to review it even if it's a bit late to be taken into > account. (I think the Contribution Period ended on Nov 4, and today, > Nov 9, is the last day for us to select interns.) Thank you for taking your time to review my proposal despite its lateness, I sincerely appreciate it. I've been at the period in the semester where balance gets a little bit 'tricky', so, I was putting in my last minute efforts. I had, however, submitted some of the 'required' details in the Outreachy portal before the deadline . > > Thank you anyway for being interested in this project and for sending > this proposal! > > > Below is its basic structure: > > > > UNIFY ref-filter FORMATS WITH OTHER --pretty FORMATS > > [...] > > > Abstract > > > > Git has an old problem of duplicated implementations of some logic > > such as the four different implementations for formatting command > > outputs for different commands. > > I am not sure if there are still four different implementations. As > far as I remember, we have been trying to unify: > > - `git for-each-ref`, `git branch` and `git tag` formats into the > ref-filter formats: > > done by Karthik Nayak (GSoC 2015) > > - `git cat-file` formats and the ref-filter formats: > > started by Olga Telezhnaya (Outreachy 20217-2018), > continued by ZheNing Hu (GSoC 2021), > but still not finished due to tricky performance issues > > - ref-filter formats and pretty formats: > > started by Hariom Verma (GSoC 2020) > continued a bit by Jaydeep Das (GSoC 2022) > but still not finished (although there doesn't seem to be hard issues), > so proposed for Outreachy 2022-2023 > > > Ref-filter {.c.h} and pretty-lib > > {.c.h} formatting logic > > I am not sure it's worth talking about filenames as early in this > proposal. Also, on the current master branch, code for the pretty > formats seems to be in pretty.{c,h} not pretty-lib.{c,h}. > I understand, I am still doing further research on this project, to understand it better. I was also following Hariom's commits and branches, which could have caused the confusion of me naming it pretty-lib(as he has) instead of pretty (as is in git). I am yet to begin looking through Jaydeep's work as well. > > have been no different and require(/d) > > unification, which will help to simplify adding new functionality as > > Git continues to develop. > > > > This project was initially proposed by Hariom Verma following his FOSS > > contributions to Git and Olga<olyatelezhnaya@xxxxxxxxx>’s work on > > ‘Unifying Git’s format languages’. > > See above for more details. (Yeah, Olga worked on a project named > ‘Unifying Git’s format languages’, but it was actually about using > ref-filter formats in `git cat-file`.) > > > In his final report, he had completed almost all pretty format > > implementation with a few challenges : > > > > 30% Log related failing tests on branch pretty-lib-2.0.2 > > > > Inability of pretty-lib {.c.h} to handle unknown formatting options. > > Yeah, Hariom wanted to create pretty-lib.{c,h} files, but I think this > was not necessary so it wasn't done. > > > Mailmap logic in ref-filter requires modification due to the new email > > options which do not allow rebasing and consequently affects the MBOX > > commit format. > > > > MBOX commit format. > > > > Completing the work and Rebasing a few other pretty-lib branches with > > features such as fix-graph3 using Junio's way to pretty-lib-2.0.2 > > I think it would have been better to summarize things a bit better, > and to avoid talking about low level details that are sometimes not > relevant anymore, like pretty-lib. > > > He also brought attention to : > > > > Olga’s remaining work https://github.com/telezhnaya/git/commits/format > > > > The purpose of this Internship Project is to solve the challenges, > > submit well-functioning patches and increase functionality and > > simplicity in pretty-lib {.c.h}. > > Here also I am not sure it's a good idea to talk about pretty-lib. > > > Deliverables > > > > The purpose of this project having been to improve and easen the > > functionality of pretty, I aim to deliver in the following: > > > > Working on failing formats to pass tests and maintain desired functionality. > > > > Easen error identification when handling unknown formats. > > > > Update MBOX commit format so that it still holds initial settings with > > additional functionality. > > > > Modifying mailmap logic to allow additional application. > > > > Finishing work in other pretty-lib branches and merging with original > > once tests are passed successfully. > > > > Update documentation for ease of understanding > > > > Final report on the improvements made and their importance. > > I think it would be nice if the different pretty formats for which > some work is needed could be listed along with the work needed. > I will continue to edit my proposal as I do more research, despite the passed deadline (today), because it will help me, if not for this particular project, maybe in future, I will be able to apply the skills, knowledge, understanding and thought process gained from this one. > > Work that may be done if the above is completed before the end of the > > project timeline: > > > > Understanding Olga’s work in depth. > > > > Working on the formats in ref-filter that were being adopted from cat-file. > > This project is not about using ref-filter formats in `git cat-file`. > Yeah, it would be very nice if you could do it, but it's very unlikely > that you could do it on top of unifying the ref-filter and pretty > formats. (This has been discussed recently on the mailing list between > ZheNing Hu and me.) > I will look deeper into it, since well, I will still be having the 4 months holiday's time. > [...] > > > In the case of the outreachy timeline having been passed, I plan to > > work on this during the two months left in my long after-semester > > break to further my knowledge on git and remain an active member of > > the git community. > > Nice! > > [...] > > > Below is my programming plan. > > > > Programming Plan > > > > I have divided my programming plan into 5 parts, which would be as follows: > > I have basically the same comments for this section as for the previous section. > > [...] > > > This is the micro project required while submitting the proposal for > > the Outreachy 2022 program: > > https://lore.kernel.org/git/pull.1372.git.git.1667150441883.gitgitgadget@xxxxxxxxx > > Thanks for working on this micro-project! > > > Motivation > > > > Git members are welcoming, I feel it will be a good learning community > > for me to grow as an Open source contributor and software programmer, > > which is one of my personal targets. During my contribution, I > > received understandable feedback in a short period of time and was > > able to make ‘polished’ and ‘out-of-the-blue’ patches as required. > > (It’s part of the conversation thread in my microproject) This brought > > to my awareness that git is an easily approachable community for any > > programming challenges faced. > > Thanks for the kind words! > > Christian. Thank you for the feedback. I would still love to be considered in the case that Outreachy creates space for companies to accept more interns. I will also send a V2 for the proposal soon. Thanks, Debra
