Hi, On Sun, Apr 17, 2022 at 11:08 PM Jaydeep Das <jaydeepjd.8914@xxxxxxxxx> wrote: > > Sorry for being late in submitting the proposal. My end semester > examinations were over just yesterday so I somehow made this proposal > during the exam time. So here is a first review from me of your proposal. I think that you cannot update your proposal on the GSoC web site, but it would be nice if you could send an updated proposal to this mailing list soon. > ## About me: > > I am a first year undergraduate at National Institute of Technology, > Silchar pursuing B.Tech in Computer Science and Engineering. My > interests include FOSS development, Data Science and Robotics. I have > been writing Python, C and shell scripts for about 3 years now. Apart > from that I also blog[1] whenever I find an interesting topic to blog > about. During the GSoC period I also plan to blog about the new things > in git that I hope to learn. > > [1]: https://jdeep.me/ Nice that you already have a blog, as we indeed suggest GSoC contributors to blog about their GSoC work. > ## Micro-Project: > > I am still a newbie in git development and made my first (minor) > contribution in Feb 2022 [1]. This was a patch I made just to get > familiar with the patching and sending patches to the mailing list. For > my micro project, I worked on adding diff driver for the Kotlin language.[2] > The main objective was to make an xfuncname regex which matches keywords > in Kotlin syntax so that they are considered as a single token > whenever diffs are generated. Along with that, a word_regex regex pattern > was also needed so that variable names, compound operators etc are not > broken into individual tokens by git diff when there is a change in them. > For ex, if a == b is changed to a != b , then the diff should show > that entire > `==` token is replaced with the token `!=`. While working on this micro > project, I learned a lot about the contribution and review workflow of > git. It took 7 patches to incorporate all the reviews and suggestions so > yeah, It did require some patience :-). > > > Minor patch(merged in master) > [1]: > https://public-inbox.org/git/20220208092339.651761-2-jaydeepjd.8914@xxxxxxxxx/ > > Micro Project(merged in master) > [2]: > https://public-inbox.org/git/20220312044832.718356-1-jaydeepjd.8914@xxxxxxxxx/ Nice! > ## Proposal: > > Git has an old problem of duplicated implementations of some logic. For > example, Git has at least 4 implementations to format commands for > different commands. Previously, Olga Telezhnaya[1] and Hariom Verma[2] > worked on this and eliminated most of the duplicate logic. But still, > there are still some things left to do. Current task is to reuse > ref-filter logic in pretty. > > [1]: https://github.com/telezhnaya/git/commits/format > [2]: > https://public-inbox.org/git/pull.707.git.1597841551.gitgitgadget@xxxxxxxxx/ > > ## Previous Work: > Previous GSoC mentee Hariom Verma worked on this[1]. He worked on > removing duplicate logic and reuse ref-filter’s logic in pretty. > However, as per his report, some tasks are still left to do. > > -> Around 30% log related tests are failing > -> Teach pretty-lib.{c,h} to handle incorrect formatting option Maybe: s/option/options/ > -> Email/MBoxed commit format needs work > > [1]: https://harry-hov.github.io/blogs/posts/the-final-report It would be nice if you could elaborate on the different tasks that are left to do, for example by answering the following questions: - What are the different test failures left? Can you find or guess the cause of the failures? - What are the incorrect formatting options that pretty-lib.{c,h} doesn't handle well yet? What currently happens and what should happen when such an incorrect option is passed? - What kind of work is needed for the Email/MBoxed commit format? > ## GSoC Planning: > The main objective would be to start from where Hariom left and make > further improvements in the related field if time permits. > > Currently, because my end sems were just over yesterday, I am yet to do > a full reading/understanding of the pretty and ref-filter code. I plan > to first read the documentation of git-log and study the pretty formats > and their implementation. Next would be to read the code and understand > how it is working under the hood and try to find possible bugs and edge > cases where the tests fail. I have already gone through the various > must-read documentations suggested in the Hacking git[1] section of the > git-scm website: > > My First Contribution Tutorial[2] > My First Object Walk[3] You say that you want to start where Hariom left, but you don't seem to mention the tasks Hariom suggested in the planning. > Apart from that, I also have a decent understanding of git internals, > objects and porcelain commands from the Git Internals[4] documentation. > I want to start as early as possible since my main motivation for > contributing to git is to improve something that millions of people, > including me, use everyday in their day to day life. > > [1]: https://git.github.io/Hacking-Git/ > [2]: http://git-scm.com/docs/MyFirstContribution > [3]: > https://github.com/git/git/blob/master/Documentation/MyFirstObjectWalk.txt > [4]: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain > > > > Estimated Timeline: > > -> April 20 - May 14 > Read the docs and go through the codebase. Make small code contribution > if possible. > > -> May 14 - May 21 > Inactive Period > The covid lockdown is almost lifted and I would need to report back > offline to college. So I would probably be busy for a week to get > settled there. Ok, thanks for mentioning the inactive periods. > -> May 22 - June 5 > Community Bonding Period > Get in touch with the possible mentors(Christian Couder and Hariom > Verma) and discuss the possible solutions. > > -> June 6 - June 11 > Inactive Period > Will be inactive for the week due to mid semester examinations > > -> June 11 - July 24 > Coding Phase 1 > Fix the test cases that are failing > Eliminate more duplicate logic in pretty.{c,h}. > Update the documentation > > July 25 - August 20 > Coding Phase 2 (part 1) > Teach pretty.{c,h} to handle incorrect formatting options. > Make improvements in email/mboxed commit formats. > Update documentation > > > August 22 - August 27 > Inactive Period > Will be inactive for the week due to end semester examinations. > > August 27 - September 19 > Coding Phase 2 (part 2) > Start where it left off in part 1 of coding phase 2. The GSoC website says: "The standard timeline accounts for 12 week coding projects. Mentors and GSoC Contributors can agree to extend the coding period up to 22 weeks." I think it would be nice if you could tell somewhere which of the standard 12 coding weeks each of the Coding Phase corresponds to, for example like: "-> June 11 - July 24 Coding Phase 1 (coding weeks 1 and 2) ..." > During the coding phase 1, I would be able to dedicate 4 - 5 hours every > working day. On weekends, I could dedicate the entire day or take a > break depending upon the number of assignments I get. During the coding > phase 2 part 1, I will be able to dedicate 4 - 5 hours easily except the > hours may decrease some days before the end semester examinations. Ok. > ## Blogging during the contribution period: > I plan to write bi monthly/monthly blogs during the contribution period > which I would post on my personal website[1]. We prefer weekly blog posts if possible, especially during the coding weeks, even if the posts are smaller. > I would write about my > progress and the new things that I will learn when I contribute to git. > I also plan to make a complete video tutorial after the GSoC period > about the contribution workflow in the git codebase since I believe it > would have greatly helped newcomers (like me) to get started quickly. > > [1]: https://jdeep.me/posts/ Nice idea! > ## Post GSoC: > I would love to explore the git codebase and I am particularly > interested in the sparse index feature of git. I would also love to > co-mentor someone someday when I get more experience in the codebase. I > have also noticed that there are some lesser known/underrated features > of git ( like partial clones, sparse checkout, worktrees) and I plan to > make video tutorials on these topics too. > > ## Closing Remarks: > As a whole, I feel it would be a great learning experience for me as > this would be the first “really” big open source project where I would > be contributing to. I am really excited about being a part of the git > community. > > Eagerly waiting for review. Thanks, Christian.
