Show 8 quoted lines
>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