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

[Aryan Gupta <garyan447@gmail.com>]

On Thu, Mar 21, 2024 at 1:48 PM Patrick Steinhardt <ps@pks.im> wrote:
>
> 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.

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

> 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