| ▲ | f311a 4 days 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. |
|
| ▲ | nielsole 4 days ago | parent | next [-] |
| Alternatively if you do not have that set up, `git log -S` helps you find commits whose diff contain a specific string. |
|
| ▲ | _1tan 4 days ago | parent | prev | next [-] |
| Can you elaborate on the dependent .gitattributes file? Where can I find more information on the necessary content? Sounds super useful! |
| |
| ▲ | f311a 4 days ago | parent [-] | | You need to specify diff format, so that Git can correctly identify and parse function body. *.py diff=python | | |
|
|
| ▲ | adastra22 4 days ago | parent | prev | next [-] |
| I use git bisect literally every day. We are clearly different people :) |
| |
| ▲ | hinkley 4 days ago | parent [-] | | I 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 4 days ago | parent [-] | | Basically 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 4 days ago | parent [-] | | Ah, 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 4 days ago | parent [-] | | I'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 4 days ago | parent [-] | | Git 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 4 days ago | parent [-] | | That 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. |
|
|
|
|
|
|
|
| ▲ | PaulDavisThe1st 4 days ago | parent | prev [-] |
| I 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. |
