On Thu, 2008-08-14 at 17:25 +0100, Simon Peyton-Jones wrote: > | Although the usual policy is not to permit "unpull"s on the main repo, I > | have unpulled this patch anyway. If anyone (or any buildbot) has pulled > | this patch in the meantime, they should unpull it manually from their > | own repo. I hope this does not inconvenience anyone too much. > > Thanks Malcolm. Sorry about that everyone. > > | You can record an UNDO patch and push that. > | > | That should work for everyone else without them needing to take any > | action. They'll end up with both patches the 'do' and the corresponding > | 'undo' one. > > I don't know how to make an UNDO patch. But Malcolm has solved the problem > anyway.
Here's an example of using darcs rollback: $ darcs rollback Fri Jul 11 19:07:23 BST 2008 Duncan Coutts <[EMAIL PROTECTED]> * Merge StateTrans into State and simplify Shall I rollback this patch? [yNvpq], or ? for help: y Finished rolling back. $ darcs changes --last=2 Fri Jul 11 19:07:23 BST 2008 Duncan Coutts <[EMAIL PROTECTED]> UNDO: Merge StateTrans into State and simplify Fri Jul 11 19:07:23 BST 2008 Duncan Coutts <[EMAIL PROTECTED]> * Merge StateTrans into State and simplify So now I have two patches locally, the original one and the undo one. In your example, you'd already pushed the original one. So you could then push the undo one as well. That avoids the problem that Malcolm notes, which is that with removing the patch from the server side, someone might have already pulled it in the mean time and then when you later push the real patch, it would conflict with the original incorrect patch. If the window was very narrow then perhaps nobody will be affected, but it's best to avoid removing patches from a public repo in general. Adding an inverse/undo patch is the right thing to do in this kind of situation. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
