Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > Christian Couder venit, vidit, dixit 16.03.2011 10:52: > ... >> It's already possible to deal with this problem by creating a new >> branch where the bug is fixed,... > > 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. I totally agree with Michael. If somebody has _already_ used "replace" to make an alternate history in which nobody made any mistake by masking each and every bug fixed in the past, your bisect would be easier, but that is nothing more than a theoretical daydreaming. Who in the right mind would do that? If you need fixes applied for unrelated bug to even trigger the bug you are chasing, "replace" is not a practical option. You might even be the first to notice that these "known fixes" mattered in the part of the history you happen to be bisecting, and nobody sane would have prepared such "replace" in the past just in case. Treat "replace" as nothing more than a reimplementation of "grafts" done right (i.e. can be transferred using the usual git transfer protocols); I don't want to see its use advocated for applications it is not suited. It just confuses people. -- 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