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

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]

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.

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.

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.

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.

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

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]