Re: [git-users] need explanation re git bisect

[Philip Oakley]

Hi Mark,

quick comment.

Possibly include more good commits in the list. I suspect that there are 
multiple branches that merge into master between those two tags, and that 
some of those brancfes have fork points from before the given good tag, so 
git has to search down all of those other side branches, and found one. 
Hence the report of an rc branch as the first bad commit.


Philip
- Original Message - 
From: "Marc Haber" 

Hi,

I have been trying to use git bisect to find a regression in the linux
kernel that has made the majority of my Linux KVM virtualization hosts
instable starting wit the kernel 4.14 release.

A first bisect try was between the "v4.13" tag (good) and the "v4.14"
tag (bad). I was quite astonished when the bisect quickly concentrated
on kernels numbered as 4.13-rc7, which is _earlier_ than the "good"
v4.13.

My preliminary findings were:

- 569dbb88e80deb68974ef6fdd6a13edb9d686261 is good
- ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is bad
- ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 was the result of the kernel
 bisect between 4.13 and 4.14, but is a one-character typo fix in a
 comment.
- I am also confused that ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is in
 4.13-rc7, therefore earlier than the "good" 4.13 relese

Unfortunately, it is quite hard to identify a "good" release since the
issue is not quite reproducible but can show itself after running the
system under load for days.

In the second try, I tried bisecting between those two commits. This
quickly resulted in:
The merge base cc4a41fe5541a73019a864883297bd5043aa6d98 is bad.
This means the bug has been fixed between
cc4a41fe5541a73019a864883297bd5043aa6d98 and
[569dbb88e80deb68974ef6fdd6a13edb9d686261].

569dbb88e80deb68974ef6fdd6a13edb9d686261 is Linux 4.13 and is good
cc4a41fe5541a73019a864883297bd5043aa6d98 is Linux 4.13-rc7 and is bad.

Bisecting between those ends up in:
[6/4993]mh@fan:~/linux/git/bisect/linux ((v4.13) *|BISECTING) $ git
bisect good
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 [5/4992]mh@fan:~/linux/git/bisect/linux ((v4.13) *|BISECTING) $ git
bisect log
git bisect start
# bad: [cc4a41fe5541a73019a864883297bd5043aa6d98] Linux 4.13-rc7
git bisect bad cc4a41fe5541a73019a864883297bd5043aa6d98


What am I doing wrong here? Any idea what to do here?

Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im 
Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 
1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 
1600421


--
You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout. 


--
You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] need explanation re git bisect

[Marc Haber]

Hi,

I have been trying to use git bisect to find a regression in the linux
kernel that has made the majority of my Linux KVM virtualization hosts
instable starting wit the kernel 4.14 release.

A first bisect try was between the "v4.13" tag (good) and the "v4.14"
tag (bad). I was quite astonished when the bisect quickly concentrated
on kernels numbered as 4.13-rc7, which is _earlier_ than the "good"
v4.13.

My preliminary findings were:

- 569dbb88e80deb68974ef6fdd6a13edb9d686261 is good
- ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is bad
- ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 was the result of the kernel
  bisect between 4.13 and 4.14, but is a one-character typo fix in a
  comment.
- I am also confused that ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is in
  4.13-rc7, therefore earlier than the "good" 4.13 relese

Unfortunately, it is quite hard to identify a "good" release since the
issue is not quite reproducible but can show itself after running the
system under load for days.

In the second try, I tried bisecting between those two commits. This
quickly resulted in:
The merge base cc4a41fe5541a73019a864883297bd5043aa6d98 is bad.
This means the bug has been fixed between
cc4a41fe5541a73019a864883297bd5043aa6d98 and
[569dbb88e80deb68974ef6fdd6a13edb9d686261].

569dbb88e80deb68974ef6fdd6a13edb9d686261 is Linux 4.13 and is good
cc4a41fe5541a73019a864883297bd5043aa6d98 is Linux 4.13-rc7 and is bad.

Bisecting between those ends up in:
[6/4993]mh@fan:~/linux/git/bisect/linux ((v4.13) *|BISECTING) $ git
bisect good
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 [5/4992]mh@fan:~/linux/git/bisect/linux ((v4.13) *|BISECTING) $ git
bisect log
git bisect start
# bad: [cc4a41fe5541a73019a864883297bd5043aa6d98] Linux 4.13-rc7
git bisect bad cc4a41fe5541a73019a864883297bd5043aa6d98


What am I doing wrong here? Any idea what to do here?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.