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. Thanks, Christian. -- 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