On Mon, Mar 22, 2010 at 3:25 PM, Marc Branchaud <marcnarc@xxxxxxxxxxx> wrote: > +Sometimes you're in a situation like this > + > + P---o---o---M---x---x---W---x > + \ / > + A---B---C > + > +where you: > + > + - Need to rewrite one of the commits on the A-B-C branch; and > + > + - Want the rewritten A-B-C branch to still start at commit P (perhaps P > + is a branching-off point for yet another branch, and you want be able to > + merge A-B-C into both branches). > + > +The natural thing to do in this case is to checkout the A-B-C branch and use > +"rebase -i A" to change commit B. However, this does not rewrite commit A, > +and you end up with this: > + > + P---o---o---M---x---x---W---x > + \ / > + A---B---C <-- old branch > + \ > + B'---C' <-- rewritten branch > + > +To merge A-B'-C' into the mainline branch you would still have to first revert > +commit W in order to pick up the changes in A, but then it's likely that the > +changes in B' will conflict with the original B changes re-introduced by the > +reversion of W. I think you need to clarify in the above text that W is a revert of M. I was very confused by this at first. Other than that, I'll leave it to others more opinionated than me to comment on whether regenerating a commit just for the sake of regenerating it is actually desirable or not :) Have fun, Avery -- 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