From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:19
Andrew Morton [off-list ref] writes:
quoted
As humans, we can tell that it is not very plausible that the
EXTRAVERSION change caused whatever breakage you are chasing,
but sorry, from your log, I think bisect is doing the right
thing.
I don't think humans are well-suited to using git.
I did not mean that ;-). Git is not as smart as humans.
My current theory is that I was bisecting Linus's tree all along.
Sorry, I did not realize that was _not_ what you were doing.
Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was
not, so I just assumed your bug was between those two.
If your suspect was merged between these two versions, then it
does not matter which branch you were _on_ when you started to
bisect.
You mark points that are good and bad, and wander around in the
commit DAG, trying to narrow down the distance between known
good points and bad points while bisecting, and during that, you
are not really on _any_ branch.
From: Andrew Morton <hidden> Date: 2016-06-15 22:42:19
Junio C Hamano [off-list ref] wrote:
Andrew Morton [off-list ref] writes:
quoted
quoted
As humans, we can tell that it is not very plausible that the
EXTRAVERSION change caused whatever breakage you are chasing,
but sorry, from your log, I think bisect is doing the right
thing.
I don't think humans are well-suited to using git.
I did not mean that ;-). Git is not as smart as humans.
quoted
My current theory is that I was bisecting Linus's tree all along.
Sorry, I did not realize that was _not_ what you were doing.
Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was
not, so I just assumed your bug was between those two.
If your suspect was merged between these two versions, then it
does not matter which branch you were _on_ when you started to
bisect.
You mark points that are good and bad, and wander around in the
commit DAG, trying to narrow down the distance between known
good points and bad points while bisecting, and during that, you
are not really on _any_ branch.
So how am I supposed to find this bug in Jeff's tree?
I do git-checkout -f git-netdev-all, then do the bisection and I come up
with junk.
<does it all again>
It points at this:
commit a03b1950521466e007288a25c9fc7ac7f05a97e5
Merge: 0b310f36d7d96e27f6941ec0f9b95e15142f1e78 c6f0d75a2defe8c7d8bf9f78de891cedc46b4b3e
Author: Jeff Garzik [off-list ref]
Date: Tue Jan 31 11:52:21 2006 -0500
Merge branch 'upstream-fixes'
git-bisect start
# good: [d834a41c966c6a20368fadb59248740935e6fbae] ipw2200: do not sleep in ipw_request_direct_scan
git-bisect good d834a41c966c6a20368fadb59248740935e6fbae
# bad: [b0afb58735e5dae05cb06ce6d0ca3073f390e9dc] Merge branch 'upstream'
git-bisect bad b0afb58735e5dae05cb06ce6d0ca3073f390e9dc
# good: [0c19585b0d2f6817dd9af607650d3f6cae2fd8bc] uml: typo fixup
git-bisect good 0c19585b0d2f6817dd9af607650d3f6cae2fd8bc
# good: [71baa1a599c04ab56ebf5fdb8d03abd0d601462f] [MIPS] Get rid of unnecessary prototypes. Fixes and optimizations for HZ > 100.
git-bisect good 71baa1a599c04ab56ebf5fdb8d03abd0d601462f
# good: [d04e4e115bd9df2b748cb30abd610f3c0eb1e303] eeh_driver NULL noise removal
git-bisect good d04e4e115bd9df2b748cb30abd610f3c0eb1e303
# good: [9908104935325bd6beba67d637b6f5396d47075c] [IPV6]: Address autoconfiguration does not work after device down/up cycle
git-bisect good 9908104935325bd6beba67d637b6f5396d47075c
# good: [0b310f36d7d96e27f6941ec0f9b95e15142f1e78] Merge branch 'upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
git-bisect good 0b310f36d7d96e27f6941ec0f9b95e15142f1e78
# bad: [70c07e02625ec46d0ffbfce1acef42d660803528] Merge branch 'viro'
git-bisect bad 70c07e02625ec46d0ffbfce1acef42d660803528
# good: [2746b8623abce815aaae7afc946b1b39f8436f5a] Merge branch 'net.b0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/bird
git-bisect good 2746b8623abce815aaae7afc946b1b39f8436f5a
# bad: [6bd0e10e53cc4824cd8cdaab8c370e53ab2e23c2] Merge branch 'sundance'
git-bisect bad 6bd0e10e53cc4824cd8cdaab8c370e53ab2e23c2
# bad: [3c9b3a8575b4f2551e3b5b74ffa1c3559c6338eb] Merge branch 'master'
git-bisect bad 3c9b3a8575b4f2551e3b5b74ffa1c3559c6338eb
# bad: [c0d3c0c0ce94d3db893577ae98e64414d92e49d8] [netdrvr] schedule eepro100 for removal
git-bisect bad c0d3c0c0ce94d3db893577ae98e64414d92e49d8
# bad: [a03b1950521466e007288a25c9fc7ac7f05a97e5] Merge branch 'upstream-fixes'
git-bisect bad a03b1950521466e007288a25c9fc7ac7f05a97e5
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:19
Andrew Morton [off-list ref] writes:
Junio C Hamano [off-list ref] wrote:
quoted
Andrew Morton [off-list ref] writes:
quoted
My current theory is that I was bisecting Linus's tree all along.
Sorry, I did not realize that was _not_ what you were doing.
Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was
not, so I just assumed your bug was between those two.
So how am I supposed to find this bug in Jeff's tree?
Sorry, this question is what I do not quite understand.
Here is my understanding of the situation.
- Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was
introduced. You know rc1 works fine but rc2 is bad.
- You suspect that changes introduced by merging Jeff's tree
at some point between -rc1 and -rc2 may be causing this.
Am I totally misunderstanding the situation?
Bisecting, starting from -rc1 and -rc2 marked good and bad would
find the bug provided if the symptom is caused by a single bug
(that is, before that commit things work but after that things
stop working) that is in any commit that was not present in -rc1
but in -rc2. That includes what was merged from Jeff's tree, so
even if you were "bisecting Linus' tree all along", if -rc1 was
good and -rc2 was bad, that would have found the bug in Jeff's
tree (if it was what introduced the bug). As long as that was
merged between these two -- but otherwise breakage in -rc2 would
not have anything to do with Jeff's tree, so that is one reason
I am confused by your emphasis on "in Jeff's tree" part.
good bad
-rc1 -rc2
---o---o---o---*---*---*---*---*---*
\ \ / /
\ *---* /
\ /
*---*---*---*---*
Jeff's
Your bisection that starts with good -rc1 and bad -rc2 would try
to bisect commits that are not reachable from good ones (that
is, parents before good ones are assumed to be good, since
bisect is only good to look for a single regression), so at the
beginning, all '*' commits are suspects. bisection picks one of
them and after testing it, depending on it is good or bad, mark
about the half of the remaining graph "unsuspected". So even if
you start out with two commits on Linus' tree, you will wander
into Jeff's tree, if the suspect commit is in there. I am
confused by your emphasis on "in Jeff's tree" part.
Maybe you are saying that you _know_ what broke was from Jeff's
tree, and felt bisecting other parts of Linus' tree was
wasteful?
If so, you can use gitk to visualize the graph, find the merge
Linus' did to merge from Jeff (and I presume you already did so
and that is why you are suspecting Jeff's tree). Mark that as
bad, not -rc2. Also if you know the commit on Linus' tree
before that merge was good (and I presume you already did so
and that is why you are suspecting Jeff's tree), mark that as
good, not -rc1.
-rc1 good bad -rc2
---o---o---o---o---o---o---*---o---o
\ \ / /
\ o---o /
\ /
*---*---*---*---*
Jeff's
Then your bisect will walk over commits on Jeff's tree.
Is this helpful, or am I still completely useless?
From: Andrew Morton <hidden> Date: 2016-06-15 22:42:19
Junio C Hamano [off-list ref] wrote:
Sorry, this question is what I do not quite understand.
Here is my understanding of the situation.
- Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was
introduced. You know rc1 works fine but rc2 is bad.
- You suspect that changes introduced by merging Jeff's tree
at some point between -rc1 and -rc2 may be causing this.
Am I totally misunderstanding the situation?
yup ;)
The bug is in Jeff's tree only
(git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)
so I wanted to perform the bisection on the git-netdev-all branch.
So I did a `git log git-netdev-all' and looked at where the ipw2200 changes
were and then decided that the 2.6.16-rc1 and 2.6.16-rc2 commits straddled
those changes nicely, so I chose those as the bisection starting points.
The bug is in Jeff's tree only
(git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)
so I wanted to perform the bisection on the git-netdev-all branch.
Actually, what you should do, is not play any games at all, but just tell
"git bisect" what the problem is. It will do the right thing.
So in this case, what you do is _literally_ to
# fetch Jeff's tree (you obviously had this already, but I just
# want to point it out as a "name that branch" thing)
git fetch netdev-all
# we know that that tree is broken
git bisect start
git bisect bad netdev-all
# We know that Linus' top-of-tree doesn't have the bug
git bisect good origin
and off you go. It absolutely magically does the right thing, and will
bisect stuff that is only in the netdev branch and not in my tree. No
guessing necessary, no need to try to figure out what the differences are.
git will do it all for you.
And notice how it will work perfectly well, even if the two points you
have tested AREN'T EVEN DIRECTLY RELATED! The "good" and "bad" points do
not have to have any direct relationship other than a common parent
_somewhere_. "git bisect" really is that good.
(The above is obviously assuming that "origin" is set to my tree,
self-aggrandizing bastard that I am, and that you've set up a
.git/remotes/netdev-all file pointing to Jeff's tree - your setup may vary
from this, so you'd have to change the lines to match)
Linus
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:19
Dear diary, on Tue, Feb 14, 2006 at 01:56:20AM CET, I got a letter
where Andrew Morton [off-list ref] said that...
Junio C Hamano [off-list ref] wrote:
quoted
Sorry, this question is what I do not quite understand.
Here is my understanding of the situation.
- Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was
introduced. You know rc1 works fine but rc2 is bad.
- You suspect that changes introduced by merging Jeff's tree
at some point between -rc1 and -rc2 may be causing this.
Am I totally misunderstanding the situation?
yup ;)
The bug is in Jeff's tree only
(git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)
so I wanted to perform the bisection on the git-netdev-all branch.
So I did a `git log git-netdev-all' and looked at where the ipw2200 changes
were and then decided that the 2.6.16-rc1 and 2.6.16-rc2 commits straddled
those changes nicely, so I chose those as the bisection starting points.
But aren't those commits on the Linus' "branch", not containing any
commits specific to git-netdev-all?
I imagine the situation is like:
* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)
\ \ \
* -- * -- * -- * -- * -- * -- * -- * -- * -- M - - (git-netdev-all)
Then, if you bisect between -rc2 and -rc1, you will never actually get
to the git-netdev-all branch, since there are no such commits inbetween
-rc2 and -rc1. Even if you consider this:
* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)
\ / \ \
* -- X -- Y -- Z -- A -- * -- * -- * -- * -- M - - (git-netdev-all)
git-bisect will consider the X, Y, Z commits (since they are part of the
ancestry between -rc and -rc2), but not commits from A on - it can't
reach them topologically if it considers only commits between -rc1 and
-rc2:
* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2
\ /
- X -- Y -- Z
Now, perhaps what you meant is that "when -rc2 got merged to netdev-all,
things were already broken". In this case, what you want to do is to use
the commit M as the bisect bad point. Then, bisect will walk this
subgraph:
* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2
\ / \ \
- X -- Y -- Z -- A -- * -- * -- * -- * -- M
I agree that this can be kind of confusing; I'm not sure how to avoid
this. Perhaps git-bisect should warn if when bisecting between Q and P,
there exists a path between HEAD and P avoiding Q...?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:19
Dear diary, on Tue, Feb 14, 2006 at 02:15:12AM CET, I got a letter
where Petr Baudis [off-list ref] said that...
Dear diary, on Tue, Feb 14, 2006 at 01:56:20AM CET, I got a letter
where Andrew Morton [off-list ref] said that...
quoted
Junio C Hamano [off-list ref] wrote:
quoted
Sorry, this question is what I do not quite understand.
Here is my understanding of the situation.
- Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was
introduced. You know rc1 works fine but rc2 is bad.
- You suspect that changes introduced by merging Jeff's tree
at some point between -rc1 and -rc2 may be causing this.
Am I totally misunderstanding the situation?
yup ;)
The bug is in Jeff's tree only
(git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)
so I wanted to perform the bisection on the git-netdev-all branch.
So I did a `git log git-netdev-all' and looked at where the ipw2200 changes
were and then decided that the 2.6.16-rc1 and 2.6.16-rc2 commits straddled
those changes nicely, so I chose those as the bisection starting points.
But aren't those commits on the Linus' "branch", not containing any
commits specific to git-netdev-all?
I imagine the situation is like:
* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)
\ \ \
* -- * -- * -- * -- * -- * -- * -- * -- * -- M - - (git-netdev-all)
Then, if you bisect between -rc2 and -rc1, you will never actually get
to the git-netdev-all branch, since there are no such commits inbetween
-rc2 and -rc1. Even if you consider this:
* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)
\ / \ \
* -- X -- Y -- Z -- A -- * -- * -- * -- * -- M - - (git-netdev-all)
git-bisect will consider the X, Y, Z commits (since they are part of the
ancestry between -rc and -rc2), but not commits from A on - it can't
reach them topologically if it considers only commits between -rc1 and
-rc2:
* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2
\ /
- X -- Y -- Z
I got this one (and consequently, the following one) wrong - obviously,
it should read as
2.6.16-rc1 -- * -- * -- 2.6.16-rc2
/
X -- Y -- Z
since the "asterisk" commit is already behind -rc1.
Pedagogical excursion:
All those commit intervals are really set differences - if you have
commit A and commit B,
[A,B] = B \cup (ancestry(B) \ ancestry(A))
or if you don't like math, color B and all its ancestors blue in
your head, and then color all the A ancestors black. The commits
that stay blue are in the [A,B] interval.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams