Re: [GSoC][RFC][Proposal] Unify ref filters in pretty.{c,h}

From: Christian Couder <christian.couder@gmail.com>
Date: Apr 22, 2022, 08:42 UTC
Message-ID: <CAP8UFD0xwDYj-qxeZjFXzpbDCTs-U4j1=XwOUQXb-XqZP+8Mxg@mail.gmail.com>
In-Reply-To: <7f2e9c1b-1d01-00af-810f-c81dd38c12ad@gmail.com>

Hi,

On Sun, Apr 17, 2022 at 11:08 PM Jaydeep Das <jaydeepjd.8914@gmail.com> 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.

Show 11 quoted lines

> ## 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.

Show 26 quoted lines

> ## 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@gmail.com/
>
> Micro Project(merged in master)
> [2]:
> https://public-inbox.org/git/20220312044832.718356-1-jaydeepjd.8914@gmail.com/

Nice!

Show 20 quoted lines

> ## 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@gmail.com/
>
> ## 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?

Show 15 quoted lines

> ## 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.

Show 25 quoted lines

> 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.

Show 29 quoted lines

> -> 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) ..."

Show 5 quoted lines

> 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.

Show 7 quoted lines

> 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!

Show 15 quoted lines

> ## 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.