Russel Winder <[email protected]> writes: > Gary, > > This seemingly just gets worse. > > From: http://mercurial.selenic.com/wiki/Backout > > Warning > > Backing out a merge will lead to trouble if you ever want to > redo the merge. The only safe way to deal with a bad merge is to > abandon the branch. > > I think the corollary of this for the SCons workflow is "we're screwed".
I believe I added that warning :) And the example on the wiki page should show that this behavior is a consequence of how three-way merges work -- as far as I remember. As a side remark: It would be good if someone could write the Mercurial mailinglist ([email protected]) with a summary of what's wrong and how to proceed -- there's a lot of clever people there, including Matt Mackall who designed Mercurial. Reverting a published merge is hard (I believe it's hard in Git too). That is one reason why premature merging is really bad: you *commit* yourself to the result in a strong way. One way to "fix" a merge in Mercurial is to abandon it: redo the merge (correctly this time) and abandon the bad merge: $ hg update "p1(bad-merge)" $ hg merge "p2(bad-merge)" $ hg commit -m "Better version of bad-merge" $ hg update bad-merge $ hg commit --close-branch -m "Use <new-merge> instead" That will leave you with a dangling topological head, but that is fine with modern Mercurial. People who have local work based on bad-merge will simply rebase it to new-merge and push. -- Martin Geisler
pgp4dHNssgbTN.pgp
Description: PGP signature
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
