Re: git bisect and the merge from hell

"Luck, Tony" [off-list ref] writes:

Sometime between -rc1 and -rc2 the ia64 kernel picked up a bug
that prevents booting a UP kernel on my workstation (I recycled
the serial cable to hook up a new machine, so I don't have the
OOPS).

So I thought I'd use git bisect to narrow it down.  A few iterations
in it picked the merge from hell, and two iterations after that it
appears to have wandered into the weeds and picked something from
before -rc1.

 $ git describe 3c5c363826e435cf4d54d917202567e5b57cae5f
 v2.6.15-g3c5c3638

Is this normal?

I haven't looked at your ancestry graph yet (I am at work
writing this message during my lunch break), but if one of the
branches merged between rc1 and rc2 were forked from the
mainline at a commit before rc1, that is an expected behaviour.
Suppose:

       .o---o---o--- ... ---o---o.
      /                           \
     /                             \
 ---o---o---*---o--- ... ---o---o---*---o---o---*
            rc1                     octopus     rc2

And you said "rc1 was OK but rc2 is BAD".  Now, the bug may well
be somewhere between rc1 and Len's octopus on the lower
development track.  But the problem may have been introduced by
some of the commits on the upper development track that bypassed
rc1.  They are not descendant of rc1, and describe would say
they come after v2.6.15.

The side branch merged during that timeperiod that forked before
rc1 may not be the one merged by Len's octopus but may be merged
by some other merge, but the story is the same.