>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 Right, and that makes it much more difficult when you want to be selective about which fixes you want to apply. -- Yann Dirson - Bertin Technologies -- 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