1

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.

Michał Walenciak
  • 4,257
  • 4
  • 33
  • 61
  • You mentioned that there might be one or merge commits in the history you are trying to bisect. Are you certain that you are following the correct parent? – Tim Biegeleisen Nov 30 '19 at 09:39
  • @TimBiegeleisen what I checked was to make sure that commit #1 is an indirect parent of current master. Is that what you meant? – Michał Walenciak Nov 30 '19 at 09:42
  • 1
    Maybe not. Git bisect goes back in history and finds the point when things stopped breaking. But if there be a merge commit, then there must be a step where you tell Git which parent to follow. I am suggesting that maybe Git followed the wrong parent when crossing the merge commit. – Tim Biegeleisen Nov 30 '19 at 09:46
  • @TimBiegeleisen that's very likely. There were many many merges. It could choose wrong path. But I cannot recall bisect asking me which path to follow. – Michał Walenciak Nov 30 '19 at 09:58
  • 1
    Bisect, even when runs automatically, leaves full of of its steps, you can get them from [git bisect log](https://git-scm.com/docs/git-bisect#_bisect_log_and_bisect_replay) and try to find the one which you believe went wrong. – max630 Nov 30 '19 at 10:38
  • @max630 I'll give it a try, thank you. However, as said, history is very complex and I may have troubles figuring out what's going on. – Michał Walenciak Nov 30 '19 at 13:09

1 Answers1

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.

Philip Oakley
  • 13,333
  • 9
  • 48
  • 71
  • https://git-scm.com/docs/git-bisect#_cutting_down_bisection_by_giving_more_parameters_to_bisect_start is the place in the manual for the extra good revisions, and telling git which file to look at. – Philip Oakley Dec 01 '19 at 20:38