Re: git bisect and the merge from hell
- From
Junio C Hamano <junkio@cox.net>
- Date
- Feb 3, 2006, 20:34 UTC
- Message-ID
- <7virrwdvv1.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <200602031947.k13JlaDr003720@agluck-lia64.sc.intel.com>
"Luck, Tony" <tony.luck@intel.com> writes:
Show 14 quoted lines
> 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 rc2And 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.