Re: [RFE] allow git bisect to figure out in which revision a bug was fixed

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 22, 2009, 02:41 UTC
Message-ID: <7vy6qhwib6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.0907212118550.30629@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 10 quoted lines

> On Tue, 21 Jul 2009, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>> 
>> > Why not simply automatically inverting the meaning of good and
>> > bad based on which commit is the ancestor of the other initially?
>> 
>> Because neither may be an ancestor of the other?
>
> In most cases it has to be, no?

Not necessarily.

I think it depends on your workflow. When you bisect a topic branch that forked from 'master' some time ago, it is not unreasonable to start it with

	$ git bisect start topic master

instead of

	$ git bisect start topic $(git merge-base master topic)

Recent bisect would force you to check the merge base first as a sanity check, but I think you already need to have determined what good and bad means at that point if you take the route you suggested.