Comment # 22 on bug 975824 from Takashi Iwai

(In reply to Jozef Kovac from comment #21)
> (In reply to Takashi Iwai from comment #19)
> > (In reply to Jozef Kovac from comment #18)
> > > polo@polo:~> cd linux-stable
> > > polo@polo:~/linux-stable> git commit bad
> > > error: pathspec 'bad' did not match any file(s) known to git.
> > 
> > Not "git commit bad" but "git bisect bad".  It's a sub-command of git-bisect.
> > Also "git bisect good" as well for a good commit.
> 
> 
> 
> well it means: 
> 
> git bisect start
> # good: [2d5f6b0413359df065fd02d695c08bbc7d998bbd] Linux 4.1.17
> git bisect good 2d5f6b0413359df065fd02d695c08bbc7d998bbd
> # bad: [83fdace666f72dbfc4a7681a04e3689b61dae3b9] Linux 4.1.18
> git bisect bad 83fdace666f72dbfc4a7681a04e3689b61dae3b9
> # bad: [3a1e81ad84e4d880b00ecf7ad8d03b9b772ddfa7] crypto: algif_hash - Fix
> race condition in hash_check_key
> git bisect bad 3a1e81ad84e4d880b00ecf7ad8d03b9b772ddfa7

No, no, this isn't the first bad commit.  This is merely the first check.

Now git bisect is pointing to the next commit to test.  Just build at this
state as is, install and retest.  Then give either "git bisect good" or "git
bisect bad" again depending on the result.  Then git-bisect points to yet
another point to test.

Repeat this procedure for many times (git suggests how many left) until git
shows that you reach to the first bad commit.  This is the goal.