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

From: Aryan Gupta <garyan447@gmail.com>
Date: Mar 21, 2024, 13:27 UTC
Message-ID: <CAMbn=B73ioQ8oRucG4X8anhwrnbhJRky7BSe7DKpQad85Dt5xg@mail.gmail.com>
In-Reply-To: <ZfwsnMWg12S2gV3C@tanuki>

On Thu, Mar 21, 2024 at 1:48 PM Patrick Steinhardt <ps@pks.im> wrote:

Show 47 quoted lines

>
> On Sat, Mar 16, 2024 at 07:57:49PM +0100, Aryan Gupta wrote:
> [snip]
> > -- Plan --
> > ----------------
> >
> > What is Git Bisect?
> >
> > Git Bisect is a git command which helps to find which commit
> > introduced the bug into the codebase at a faster rate by leveraging
> > the power of binary search.
> >
> >
> > The project idea is relatively easy to understand by the description
> > itself. Git bisect stores some state files such as BISECT_START,
> > BISECT_FIRST_PARENT etc which looks very similar to the naming
> > convention used for creating the refs file. Due to this similar naming
> > convention it sometimes causes unexpected results when these state
> > files are confused as the ref files.
> >
> > In order to fix this problem we can create a new ".git/bisect-state"
> > directory and store all the state files which belong to the
> > git-bisect(1) command in that directory as proposed by Patrick and
> > store all the files as follows.
> >
> >
> > - BISECT_TERMS -> bisect-state/terms
> > - BISECT_LOG -> bisect-state/log
> > - BISECT_START -> bisect-state/start
> > - BISECT_RUN -> bisect-state/run
> > - BISECT_FIRST_PARENT -> bisect-state/first-parent
> > - BISECT_ANCESTORS_OK -> bisect-state/ancestors-ok
> >
> > While the change looks very simple, it actually is. We will just
> > update all the paths from where these files are being accessed. When I
> > went through the code of bisect.c file I found that the path is pretty
> > easy to configure we just need to modify it at a few places. The main
> > problem is to efficiently handle the backward compatibility and
> > implement proper test cases to not let the existing things break. I
> > have already gone through the bisect.c file a couple of times just
> > reading and trying to understand all the functions and was able to
> > understand a lot of things about how it works.
>
> As you also mention further down in the section about backwards
> compatibility, the challenge of this project is not about doing those
> changes. That indeed is the trivial part of this whole project.
>

Yes.

Show 7 quoted lines

> The real challenge is figuring out with the community how to ensure that
> the change is indeed backwards compatible, and that does not only
> involve backwards compatibility with Git itself, but also with other,
> third party tools. The biggest question will be whether the refactoring
> is ultimately going to be worth it in the bigger picture, or whether we
> should really just leave it be.
>

Yeah. As mentioned in my previous email even I afraid about we will be ending with managing the bisect files at two places in order to ensure backward compatibility.

> So personally, I rather see the biggest part of this project to find
> good middle ground with the community. It's thus of a more "political"
> nature overall.
>

Yes I think we can figure it out together as a community what should be done to encounter this problem.

Show 6 quoted lines

> I don't mean to discourage you with this. I just want to state up front
> where you should expect difficulties so that you don't underestimate the
> difficulty of this project overall. It could very well happen that the
> whole idea gets shot down by the community in case we figure out that it
> is simply too risky and/or not worth it in the long run.
>

Yes, it's true.

> If you want to stick with this idea then I would strongly recommend that
> you mention this in your proposal.
>

I am open to changing to another idea, I won't mind that. Because my ultimate aim to add something (even it's a small patch) to git and if this project will never be in use. I am willing to change it. Let me know what you think about it.

> Patrick