Am 3/28/2011 16:29, schrieb Andrew Garber:
>> I'd expect this to work:
>>
>> $ git bisect start
>> $ git bisect good
>> $ git bisect bad HEAD~100
>
> So would I. I think the behavior of git bisect should be changed.
> Right now, it's trying to find the first bad commit. Instead, it
> should be trying to find the first commit where the code's good/bad
> state *changed*. IOW, it should be able to handle both of the
> following cases:
>
> good <--- oldest
> good
> good
> bad <--- the commit we want bisect to find
> bad
> bad <--- newest
>
> bad <--- oldest
> bad
> bad
> good <--- the commit we want bisect to find
> good
> good <--- newest
>
> It shouldn't matter which end we start on, so long as one end gets
> marks good, and the other end gets marked bad.
Define "end" and "other end"! It's not that trivial.
o--o--o--B
/
--o--o--o--o--G
When I have this history and I mark B as bad and G as good, will I now
find the first bad or the first good commit?
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html