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

[Marc Haber]

On Tue, Dec 26, 2017 at 05:54:21PM -, Philip Oakley wrote:
> Each time you give a 'good' history point it will trim the search history.

And adding "bad" history points will increase it, right? Marking
4.13-rc5, -rc6 and -rc7 as "bad" has increased the number of steps, and
adding "good" points beyond the first known good one doesn't reduce:

[37/5024]mh@fan:~/linux/git/bisect/linux ((v4.13-rc4) *) $ git bisect start
[38/5025]mh@fan:~/linux/git/bisect/linux ((v4.13-rc4) *|BISECTING) $ git bisect 
good
[39/5026]mh@fan:~/linux/git/bisect/linux ((v4.13-rc4) *|BISECTING) $ git bisect 
bad v4.13-rc5
Bisecting: 166 revisions left to test after this (roughly 7 steps)
[99baac21e4585f4258f919502c6e23f1e5edc98c] mm: fix MADV_[FREE|DONTNEED] TLB 
flush miss problem
[40/5027]mh@fan:~/linux/git/bisect/linux ((99baac21e458...) *|BISECTING) $ git 
bisect bad v4.13-rc7
Bisecting: 369 revisions left to test after this (roughly 9 steps)
[510c8a899caf095cb13d09d203573deef15db2fe] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
[41/5028]mh@fan:~/linux/git/bisect/linux ((510c8a899caf...) *|BISECTING) $ git 
bisect good v4.13
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?
1 [42/5029]mh@fan:~/linux/git/bisect/linux ((510c8a899caf...) *|BISECTING) $ 
git bisect bad v4.14
Bisecting: 7300 revisions left to test after this (roughly 13 steps)
[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
[43/5030]mh@fan:~/linux/git/bisect/linux ((15d8ffc96464...) *|BISECTING) $ git 
bisect good v4.13.1
Bisecting: 7300 revisions left to test after this (roughly 13 steps)
[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
[44/5031]mh@fan:~/linux/git/bisect/linux ((15d8ffc96464...) *|BISECTING) $ git 
bisect good v4.13.2
Bisecting: 7300 revisions left to test after this (roughly 13 steps)
[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
[45/5032]mh@fan:~/linux/git/bisect/linux ((15d8ffc96464...) *|BISECTING) $ git 
bisect good v4.13.3
Bisecting: 7300 revisions left to test after this (roughly 13 steps)
[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
[46/5033]mh@fan:~/linux/git/bisect/linux ((15d8ffc96464...) *|BISECTING) $ git 
bisect good v4.13.4
Bisecting: 7300 revisions left to test after this (roughly 13 steps)
[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
[47/5034]mh@fan:~/linux/git/bisect/linux ((15d8ffc96464...) *|BISECTING) $ git 
bisect good v4.13.5
Bisecting: 7300 revisions left to test after this (roughly 13 steps)
[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

Is this expected and logical behavior?

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.

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

[Marc Haber]

Hi Philip,

On Wed, Dec 27, 2017 at 04:58:16PM -, Philip Oakley wrote:
> Found the reference article about 'git describe' and the way commits can 
> 'bypass' (or appear to) the expected tags.
> 
> https://public-inbox.org/git/20140422040443.gc9...@odin.tremily.us/ shows the 
> discussion which started at 
> https://public-inbox.org/git/1397681938-18594-1-git-send-email-mcg...@do-not-panic.com/

I _think_ that I have understood the thread, but I am currently at a
loss how the observed behavior:

  - 4.13-rc7 bad
  - 4.13 release good
  - 4.13 release bad with the same issue that 4.13-rc7 had

can happen.

Anyway, I have since then found out that 4.13-rc4 is good and 4.13-rc5
is bad, and am therefore retrying the bisect between those two. It's
going to take a few weeks until I have results of that.

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.

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

[Philip Oakley]

Oh, I was wrong about 'git bisect' actually allowing --first parent (it was 
just an expectation ;-),


Though it should, based on a quick search for 'git bisect --first-parent' 
which gives quite a few mini-scripts to create the appropriate 'good' 
 commit list to see where the defect was merged in.


Philip

- Original Message - 
From: "Philip Oakley" <philipoak...@iee.org>

Hi Marc,

Found the reference article about 'git describe' and the way commits can 
'bypass' (or appear to) the expected tags.


https://public-inbox.org/git/20140422040443.gc9...@odin.tremily.us/ shows 
the discussion which started at 
https://public-inbox.org/git/1397681938-18594-1-git-send-email-mcg...@do-not-panic.com/



Philip


-Original Message-
From: git-users@googlegroups.com [mailto:git-users@googlegroups.com] On
Behalf Of Marc Haber
Sent: 27 December 2017 12:03
To: git-users@googlegroups.com
Subject: Re: [git-users] need explanation re git bisect

On Tue, Dec 26, 2017 at 05:54:21PM -, Philip Oakley wrote:
> The key points were that bisect will search *all* heirarchy paths
(unless
> you tell it different). This means that all side heirarchies are also
places
> that bisect will search.
>
> Each time you give a 'good' history point it will trim the search
history.

Is there a best practice about how to choose those history points?

> IIRC you can also use the parsing options such as --first-parent to
limit
> the search history (so you find the point that the bad issue was merged
in).

Which git subcommand has this --first-parent option, and what would be
my benefit of using it?

> One thing to do is to use 'git describe' for the good tag/commit and 
> the

> commit found by the bisect and look at the implied history of the
> ^I~J^K~L^M~N history flows, I guess that you will find that the 
> bisected

> commit is from such a side branch.

You totally lost me here. Can you explain please?

Greetings
Marc, using git on a daily basis for years but still obviously well
within the first third of the learning curve



--
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.

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

[Philip Oakley]

Hi Marc,

Found the reference article about 'git describe' and the way commits can 
'bypass' (or appear to) the expected tags.

https://public-inbox.org/git/20140422040443.gc9...@odin.tremily.us/ shows the 
discussion which started at 
https://public-inbox.org/git/1397681938-18594-1-git-send-email-mcg...@do-not-panic.com/


Philip

> -Original Message-
> From: git-users@googlegroups.com [mailto:git-users@googlegroups.com] On
> Behalf Of Marc Haber
> Sent: 27 December 2017 12:03
> To: git-users@googlegroups.com
> Subject: Re: [git-users] need explanation re git bisect
> 
> On Tue, Dec 26, 2017 at 05:54:21PM -, Philip Oakley wrote:
> > The key points were that bisect will search *all* heirarchy paths
> (unless
> > you tell it different). This means that all side heirarchies are also
> places
> > that bisect will search.
> >
> > Each time you give a 'good' history point it will trim the search
> history.
> 
> Is there a best practice about how to choose those history points?
> 
> > IIRC you can also use the parsing options such as --first-parent to
> limit
> > the search history (so you find the point that the bad issue was merged
> in).
> 
> Which git subcommand has this --first-parent option, and what would be
> my benefit of using it?
> 
> > One thing to do is to use 'git describe' for the good tag/commit and the
> > commit found by the bisect and look at the implied history of the
> > ^I~J^K~L^M~N history flows, I guess that you will find that the bisected
> > commit is from such a side branch.
> 
> You totally lost me here. Can you explain please?
> 
> Greetings
> Marc, using git on a daily basis for years but still obviously well
> within the first third of the learning curve
> 
> --
> --
> ---
> 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.
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com

-- 
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.

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

[Marc Haber]

On Tue, Dec 26, 2017 at 05:54:21PM -, Philip Oakley wrote:
> The key points were that bisect will search *all* heirarchy paths (unless
> you tell it different). This means that all side heirarchies are also places
> that bisect will search.
> 
> Each time you give a 'good' history point it will trim the search history.

Is there a best practice about how to choose those history points?

> IIRC you can also use the parsing options such as --first-parent to limit
> the search history (so you find the point that the bad issue was merged in).

Which git subcommand has this --first-parent option, and what would be
my benefit of using it?

> One thing to do is to use 'git describe' for the good tag/commit and the
> commit found by the bisect and look at the implied history of the
> ^I~J^K~L^M~N history flows, I guess that you will find that the bisected
> commit is from such a side branch.

You totally lost me here. Can you explain please?

Greetings
Marc, using git on a daily basis for years but still obviously well
within the first third of the learning curve

-- 
-
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.

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.