Re: git-bisect problem

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