Christian Couder venit, vidit, dixit 16.03.2011 10:52: > Hi, > > On Mon, Mar 14, 2011 at 10:00 PM, Ralf Wildenhues > <Ralf.Wildenhues@xxxxxx> wrote: >> git bisect is sometimes less effective than it could be in projects >> with long-lived but simple bugs (e.g., little-tested configurations). >> Rather than skipping vast revision ranges, it might be easier to fix >> them up from known bugfix branches. > > It's already possible to deal with this problem by creating a new > branch where the bug is fixed, and then using "git replace", so that > the new branch is used instead of the old one. > Please search for "git replace" in this doc: > > http://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html > >> 'git bisect fix' teaches bisect about when some known bug was >> introduced and when it was fixed, so that bisect can merge in >> the fix when needed into new test candidates. > > Perhaps some people would find it easier to use what you suggest but > using git replace may be nicer because you have to create the new > branch once, so you need to fix merge or rebase problems only once. > And the new branch may be useful not only for bisecting, for example > to recreate old versions. I'd say the replace method is perfect for transporting an existing fix "back in time" when the range of non-bisectable commits is limited. But since you have to replace the right (most recent) commit in that range it is less convenient when you have a fix due to a changed/exotic build environment or such which you do not want in your mainline. Also, you have to rebase the whole history back to the commit which introduced the problem - and that could be the root commit if the bisect problems arise from a changed toolchain, like here. Michael P.S.: Did you cull cc on purpose or did gmane mess up? Readding AM, LT, TG -- 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