Re: [GSoC][PROPOSAL v1] Refactor git-bisect(1) to make its state self-contained

[Christian Couder <christian.couder@gmail.com>]

Hi Aryan,

On Thu, Mar 21, 2024 at 2:21 PM Aryan Gupta <garyan447@gmail.com> wrote:

> On Wed, Mar 20, 2024 at 12:06 PM Christian Couder
> <christian.couder@gmail.com> wrote:

> > On Sat, Mar 16, 2024 at 7:58 PM Aryan Gupta <garyan447@gmail.com> wrote:

> > > -- About Me --
> > > ====================
> > >
> > > I have been enthusiastic about open source from the very beginning of
> > > my journey as a software developer. I’ve contributed to other
> > > open-source projects, though still a beginner, I’m generally familiar
> > > with the process of contribution. The related experiences are all in
> > > the contribution graph on my GitHub profile page [1]. In the ZAP
> > > Project[2] community, I’ve made over 50 PRs [3]. I also participated
> > > in the Google Summer of Code 2023 with the OWASP Foundation and
> > > successfully completed it as well [4]. I have contributed to some
> > > other small projects as well on GitHub.
> >
> > It's interesting to know that you have already participated in a GSoC.
> > Is there a single blog post about this or more?
>
> Here it is: https://www.zaproxy.org/blog/2023-09-11-browser-recorder/

I saw that there is one blog post, but I wanted to ask if there are
more blog posts. That's because we ask GSoC contributors to post on
their blog at least every 2 weeks and if possible every week.

> > > -- Strategies for Handling Backward Compatibility --
> > > ---------------------------------------------------------
> > >
> > > 1. Before implementing any changes, a good understanding of how
> > > git-bisect works and how it is structured is very important. So, I
> > > will thoroughly analyze the existing usage patterns of git-bisect and
> > > list down all the potential areas of impact.
> > >
> > > 2. To validate the codebase changes and ensure the stability and the
> > > backward compatibility of git-bisect command. I will write unit tests
> > > for all the required changes.
> >
> > Do you mean unit tests using the new unit test framework in C. Could
> > you show an example?
> >
>
> Not sure about what is the standard way that git uses for writing unit tests.
> Could you tell me a bit about this?

I was just asking if you planned to use the new unit test framework in
C. The "Move existing tests to a unit testing framework" project that
we propose on https://git.github.io/SoC-2024-Ideas/ is about moving
some unit tests to this new unit test framework. Please take a look at
that project to get more information about this subject.

> > > 3. I will also try to create some real scenarios where I will be
> > > manually testing the desired behavior.
> > >
> > > 4. We might also need some regression tests to test some of the
> > > functionality which can't be tested using unit tests.
> >
> > In which test script would you add them?
>
> I will be writing these in bash and will be adding it in a new test case file
> inside the git/t directory or maybe in "git\t\t6030-bisect-porcelain.sh"

It's better to always use the Unix notation for paths like
"t/t6030-bisect-porcelain.sh" starting at the root of the repo, rather
than mixing the Unix and Windows notations and adding "git/" before
the root.

> file. I will try mocking a scenario where we have the BISECT_* files available
> in the .git directory and then run git bisect using the command line and then
> check the expected results.

The t/*.sh test scripts are the right place for end-to-end tests
(sometimes called "black box" tests), but not for unit tests that
would test some C functions. Both unit tests and end-to-end tests
could be regression tests or performance tests.

> > > 4. Adding Tests
> > >     - Through testing for backward compatibility is very very
> > > important so that the changes don’t break the existing changes.
> > >
> > > 5. Documenting the changes
> > >     - This might also go side by side if mentors need some weekly
> > > documentation of the tasks done.
> >
> > Tests and documentation should be part of the patches that change the
> > behavior. So it doesn't really make sense to list them separately in
> > the timeline.
>
> Okay. Maybe a blog post could be a part of this?

We ask GSoC contributors to post weekly on their blog, so except for a
final blog post, most of the blogging should be also part of the
regular work.

Thanks for updating your proposal.