Re: Reporting bugs and bisection

david@lang.hm writes:

cross-posted to git for the suggestion at the bottom

[...]

Elsewhere in this thread someone said that the pre-git way was to do a
manual bisect where the developer would send patches backing out
specific changes to find the problem. one big difference between that
and bisecting the problem is that the manual process was focused on
the changes in the area that is suspected of causing the problem,
while the git bisect process goes after all changes. this makes it
much more likely that the tester will run into unrelated problems
along the way.

I wonder if it would be possible to make a variation of git bisect
that only looked at a subset of the tree when picking bisect points
(if you are looking for a e1000 bug, testing bisect points that
haven't changed that driver won't help you for example). If this can
be done it would speed up the reporters efforts, but will require more
assistance from the developers (who would need to tell the reporters
what subtrees to test) so it's a tradeoff of efficiancy vs simplicity.

Errr... the synopisis of git-bisect contains the following:

 git bisect start [<bad> [<good>...]] [--] [<paths>...]

so you can limit bisection to commits affecting specified subsystem.

P.S. Unfortunately git currently doesn't deal with directory renames,
so if there was sime big code restructuring one has to provide all
historic pathspecs.

-- 
Jakub Narebski
Poland
ShadeHawk on #git