On 2017-01-12 19:49, Laszlo Ersek wrote:
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
it is also important when bisecting to make 100% sure you tell git the
right thing after testing each build.
this can be complicated if some builds don't compile properly and
prevents you from building and testing that specific version.
also binary search means you cut the problem into two halves each time
and when you tell git if it is bad or good, this means you throw away
that half of the problem and then repeat the process to further isolate
the issue.
all of this is automated by git bisect, but it all depends on picking a
good and bad commit to start with and then making sure you tell git if
the current version you are testing is really good or bad.
when i tried git bisect the first time i screwed up because of this.
then i did it right and also kept track of what commits i was testing
(the output of each git bisect) since some of the versions did not build
so i had to restart the bisect at a different point.
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
