On 01/12/17 19:21, Ede Wolf wrote: > Besides my fighting with git, is it correct, that the working kernel is > labeld "bad", while the non working one "good"? May very well possible > for the workflow of dissect, just want to confirm, please > >> git bisect start >> git bisect bad v4.5.4 >> git bisect good v4.6.1
No. git-bisect always locates a regression, that is, the first commit that introduces a bug. Where things go from right to wrong. If this matches your situation (old version works, new version breaks), simply use the "good" and "bad" command line arguments verbatim. Now, if you are looking for a commit that fixes a known bug, i.e., old version is broken, new version works, but you don't exactly know what fixed it, then you have to invert the meanings. Whenever the commit under testing works, you have to say "bad", and whenever it breaks, you have to say "good". More modern git versions help automate this (for less boggling of the mind) with "git bisect terms". (See the manual.) With older git versions, git command aliases, shell aliases, or small wrapper scripts can hide the confusion. Given that you are facing a real regression, you should use the good/bad terms verbatim. From your earlier email, "4.5.7" works, "4.6" breaks, hence you should qualify the former with "good", and the latter with "bad". Also, the word is "bisect", not "dissect". https://en.wiktionary.org/wiki/bisect https://en.wiktionary.org/wiki/dissect git-bisect performs a binary search, halving commit ranges. Hence the "bi" in "bisect". Laszlo _______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
