git bisect blaming unrelated commit

Question

I had a situation at work where we have a git repo with ~80 active users working on. There was a commit #1 on feature branch modifying a file. Branch was merged into master. Some later time I have found that change introduced by commit #1 is missing on master. So I ran git bisect pointing commit #1 as good and current master as bad.

After some steps git bisect found that the commit to blame for the loss is some commit on another feature branch made months ago touching completely different code area.

I ran this bissect again and again and again. I have also asked my coworker to do it. Every time the same commit was comming out.

There is no way we could explain this behavior. It is extremely hard to investigate history and file changes manually as history is very large an complex with many many merges between branches.

Recently my coworker had similar problem with another missing piece of code in another code area. And once again bisect blamed unrelated commit.

I am completely clueless about what's going on.

Answer 1

Git bisect is designed for finding a single step change, rather than a transient change.

In many simple cases one can set the start-end range such that a transient change is converted to a step change, but in complex merge pattern that plain start-end doesn't work.

When git bisect is given a range, it also determines a suitable set of base commits such that it can create a bisectable search. (IIUC) These can be earlier than the given start point and on another branch. It is possible to add addition (IIRC) 'good' points to ensure that the good-bad cut is leans toward the right commit.

Why not also try git blame .