I've seen blog posts explaining how to do Git bisect, but how to you fix the bug, commit again and maintain the rest of the commit history?
An actual problem I faced in my project was like this (the image is just an approximation):
I had marked the top-most commit as bad
and the bottom-most commit as good
. Some of the commits below Buggy commit A
were good commits, because somewhere in-between, I had commented out the code that made Bad commit B
a bad commit. So naturally, git bisect led me first to Buggy commit B
.
I corrected the bug and when I tried to commit, I wanted the changed lines of code to be applied to the same Buggy commit B
commit. But I found out that:
- Git would always create a new commit for this
I got the
detached head
error:HEAD detached at b855e36 Changes not staged for commit: modified: main.cpp
Now what do I do?
Create a new branch (let's name it fixedit
) and commit this corrected code? If I do, then what happens to all the other commits above it? Should I do a rebase
(never done it before) of the commit above Buggy commit B
and put the entire line of commits onto the new fixedit
branch?
I would prefer that I'd just be allowed to modify the existing commit and the entire tree would remain as it is, but then I'd have to go to all the commits above Buggy commit B
and fix the buggy line in all those commits. That doesn't make sense. So how does one fix bugs and yet retain commit history properly?
UPDATE:
So I do a git bisect reset
and fix the code on the topmost commit (because I know which line of Buggy commit B
introduced the bug)?
Like I mentioned earlier, the code that caused Buggy commit B
was commented out in one of the commits just before Buggy commit A
.
- So when in my topmost commit I see that the line is commented out, I realize that the bug is somewhere else.
- During the first bisect since one of the commits between A and B was marked good, I'd choose that as the good commit for my second Git bisect attempt, and the topmost newest commit as the bad commit and then continue with Git bisect. That'd lead me to
Buggy commit A
. - Then I'd do a
git bisect reset
and correct the lines of code in the topmost code and then commit.
Ok; that makes sense. Thanks :-)
git blame
is usually more efficient to find the commit if you already know the line of code that caused the bug.git bisect
is mostly for when you have a large range of commits that might have caused a bug, and you have no idea where to look in the code.git blame
. Actually, for bad commits A and B, I didn't know which line of code caused the problem, sobisect
was necessary. After finding the commit I had a look at the files that had got modified during the commit and the diff of what changes were done. Looks like that's exactly what ablame
does. Still,blame
andshow
seem to be nice ways of getting the job done. Thanks!