4 ms·
I've used bisect a few times in my life. Most of the time, I already know which files or functions might have introduced a bug. Looking at the history of speci
by f311a 1y ago
I've used bisect a few times in my life. Most of the time, I already know which files or functions might have introduced a bug.
Looking at the history of specific files or functions usually gives a quick idea. In modern Git, you can search the history of a specific function.
>> git log -L :func_name:path/to/a/file.c
You need to have a proper .gitattributes file, though.
- _1tan 1y agoCan you elaborate on the dependent .gitattributes file? Where can I find more information on the necessary content? Sounds super useful!
- adastra22 1y agoI use git bisect literally every day. We are clearly different people :)
- hinkley 1y agoI don’t use it for myself often, but I use it fairly often when someone has to escalate a problem to me. And how you work when the shit hits the fan says a lot about you overall, IMO.
- adastra22 1y agoBasically any time I'm like "huh, that's weird," even if it is not a bug, I bisect and see when that behavior was introduced. Because (1) this is trivial and no work to do (`git bisect run` is completely autonomous), and (2) it gets me to the commit that introduces the change, which has all the context that might tell me why it is acting that way. Nothing annoys me more than a codebase with broken commits that break git bisect.
- hinkley 1y agoAh, in that case the JetBrains diff tool lets you annotate inside the diff window and I can usually walk back to where this possible off by one error was first authored that way. It probably would be slightly faster to jump to bisect. But it’s not in my muscle memory.
- adastra22 1y agoI'm not sure what you mean by "annotate inside the diff window"? If you mean see what commit added code, that's what git-blame is for. Bisect is for when you don't know which code, just the behavior.
- hinkley 1y agoGit blame doesn’t show you why line 22 has a bug in it. It only shows you who touched it last. And that’s if nobody fucked up a merge. A single line of code can have half a dozen authors. You have to pick back through the history and keep running git blame until you determine who put the bug in that line, and why. If you show the side by side diff for a commit in JetBrains, you can click show annotations and it’ll show you the blame for the before. And then you can keep going back. For a large file that saves you having to go through all the other commits that were done in completely other parts of the file. Which can be a lot for large files.
- adastra22 1y agoThat sounds more complicated than git bisect. When I bisect I have a short test script that confirms the bug. Usually, I already have this because part of the bug report/identification. I then run "git bisect run path/to/bug.sh". That's it -- it will output which commit caused the change. Those occasional times I need to confirm the presence of actual text, I use sh -c "git grep ..." as the test command.
- nielsole 1y agoAlternatively if you do not have that set up, `git log -S` helps you find commits whose diff contain a specific string.
- PaulDavisThe1st 1y agoI use this often, but it is sadly weak when used on C++ code that includes polymorphic methods/functions: /* snip */ void Object::do_the_thing (int) { } void Object::do_the_thing (float) { } /* snip*/ AFAICT, git log will never be able to be told to review the history of the second version.