Re: git bisect problems/ideas

["Aaron S. Meurer" <asmeurer@gmail.com>]

>>> Yeah, many people find it difficult to reverse the meaning of "bad"
>>> and "good" when looking for a fix. There were some suggestions at some
>>> points to do something about it. Some of the suggestions were to use
>>> some aliases for "good" and "bad", but there was no agreement. Other
>>> suggestions had a patch attached but the patch was not good enough or
>>> something.
>>> 
>>> Anyway, the restriction is that the "bad" commit cannot be an ancestor
>>> of a "good" commit. But the "good" commits need not be all ancestors
>>> of the "bad" commit. For example if you have a "master" branch and a
>>> "dev" branch that was forked from the "master" branch at one point,
>>> like that:
>>> 
>>> A-B-C-D-E <-- master
>>>     \F-G <-- dev
>>> 
>> 
>> 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".
> 
> Best regards,
> Christian.


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?

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

Aaron Meurer