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