Messages in this thread | | | Date | Sun, 13 Apr 2008 23:22:53 +0300 | From | Adrian Bunk <> | Subject | Re: 2.6.25-rc8: FTP transfer errors |
| |
On Sat, Apr 12, 2008 at 10:41:44AM +0200, devzero@web.de wrote: > >Sure. It's not about bisection specifically, but about the time a > >reporter is able to invest in addition to what went into the report > >already. But bisection is is a good example, because it's the most > >time-consuming of all the tasks routinely asked from bug reporters. > > i think the problem with git-bisect is, that it just apears complicated and magic for an end-user. > this isn`t something a kernel-developer can explain to him in a sentence (i.e. how to use etc) >...
When I ask a user to bisect, the standard boilerplate I give to the user is:
<-- snip -->
# install git
# clone Linus' tree: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# start bisecting: cd linux-2.6 git bisect start git bisect bad v2.6.21 git bisect good v2.6.20 cp /path/to/.config .
# start a round make oldconfig make # install kernel, check whether it's good or bad, then: git bisect [bad|good] # start next round
After at about 10-15 reboots you'll have found the guilty commit ("... is first bad commit").
More information on git bisecting: man git-bisect
<-- snip -->
In my experience users are able to bisect with this boilerplate (unless there are problems like e.g. other regressions hit during bisecting).
> regards > roland >...
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
| |