Re: git bisect problems/ideas

From: Christian Couder <christian.couder@gmail.com>
Date: Jan 21, 2011, 13:18 UTC
Message-ID: <AANLkTikG6Ft3Y922Aaakf28cnYs26PcRHoq9GSNj04mu@mail.gmail.com>
In-Reply-To: <0253BAE3-90F7-492C-ADF5-8B16DFFA1E44@gmail.com>

On Wed, Jan 19, 2011 at 8:44 PM, Aaron S. Meurer <asmeurer@gmail.com> wrote:

Show 15 quoted lines

>>>
>>> I don't understand how this can only be one way?  Isn't this symmetric?  In
>>> other words, how is it different from
>>>
>>> A-B-C-D-E <-- dev
>>>    \F-G <-- master
>>>
>>> as far as bisect is concerned? Or maybe I am not entirely clear on what you
>>> are saying.
>>
>> Yes, it is symmetric, so we cannot just automatically reverse the
>> meanning because there is no "after" or "before" relationship between
>> "dev" and "master".
>
> I think I understand.  What if something works in A, gets broken in C, stays broken in E, but gets fixed in G?  Should it maybe be implied by whichever one is marked as good first, A or G, if you trying to find the fix or the break?

In this case, if we are given "git bisect bad E" and "git bisect good A", yes, as A is before E, we must suppose that we are looking for the break.

But if we are given "git bisect bad E" and "git bisect good G", we have to suppose that we are looking for the break too. There are many good reasons for that:

- it's the logical default for bisect,
- if what is wanted is the fix, there has been for a long time the
possibility to just switch "bad" and "good",
- the user might not even realize that E and G have no "after" or
"before" relationship.

> If no, I think --reverse is actually a suitable fix.

Yeah, but I think that what Dscho started was probably better. The problem is just that it is not so simple to implement and no one yet has been interested enough or took enough time to finish it.

Best regards, Christian.