Regression search with Git bisecting #git #commandlinefu #regression #bisect

regression_search_with_git_bisecting.md

Regression search with Git bisecting

Git bisecting

Normally you mark commits as good OR bad, and using divide-and-conquer strategy. Eventually you will find the first bad commit in a few passes (even with hundreds of commits).

# 0. Start bisecting process
git bisect start

# 1. Mark current branch that has the bug
git bisect bad

# 2. Mark a tag that is working, or use a commit SHA directly
git bisect good v1.2.3

# 3. Git will automatically checkout the commit between the good and bad
#    You will have to identify if that commit is good or bad, and mark with 
git bisect bad
# OR
git bisect good

Git reverse bisecting (finding fix instead of regression)

When you look for a fix instead of a regression, it can be quite hard to twist your brain into choosing the correct bisect command between git bisect bad and git bisect good.

A typical sign of this "wrong way" when you get following error message after issueing git command:

Some good revs are not ancestors of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistook good and bad revs?

Git v2.7.0 introduced new and bad as new terms. You might use this to (re)define them with proper semantics:

git bisect start --term-new=fixed --term-old=unfixed

# mark as 'good'
git bisect fixed

# mark as 'bad'
git bisect unfixed

Find first software version (tag) that contains the regression commit

Assumes the project/repository makes use of tags for release management.

git -c "versionsort.suffix=-" tag --sort=version:refname --contains <commitsha1> | head -n1