On Wed, 2009-05-13 at 10:28 +0200, Jacek Politowski wrote:
> On Wed, May 13, 2009 at 08:25:08AM +0200, Michel Dänzer wrote:
> >On Wed, 2009-05-13 at 02:09 +0200, Jacek Politowski wrote:
>
> >> Going upwards, from working to buggy revision, I treated FTBFS
> >> (failing to build from source) commits as "bad" for git bisect. Going
> >> from buggy revision downwards - to working one - I treated FTBFS
> >> commits as "good" for git bisect.
>
> >It's better not to mark such commits as good or bad at all. Either use
> >git bisect skip or switch to a nearby commit that can be used to verify
> >the problem being bisected manually.
>
> Maybe it's better, but with git bisect skip I'd still be in testing
> session - I tried that. I also tried skipping more (N - for N={1..4})
> revisions with git reset --hard HEAD~N, but it was also pointless
> then.
The point is that if you say git bisect good/bad for a commit where you
couldn't verify the problem you're bisecting, the result of the bisect
run may be incorrect.
> Judging from compilation errors, I made an assumption that it was
> always the same error causing compilation failure for me. Now I have
> narrowed down the list of possible commits to 46 and can start with
> narrower boundaries - manageable even with git bisect skip (to
> proove/contradict that all the commits in between are failing to
> build).
Also note that if you know the fix for a build problem and you're
confident it doesn't affect the problem you're bisecting, it's
legitimate to manually apply the build fix.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
