On Sun, Oct 14, 2012 at 12:17 PM, Russel Winder <[email protected]>wrote:
> On Sun, 2012-10-14 at 16:10 +0200, Thomas Berg wrote: > […] > > > have run into this too. When a branch is merged prematurely, and > > rewriting history isn't an option, the solution is to "revert" the > > merge on the main branch, and then "revert the revert" on the branch > > where you want the changes back for further development. Sounds > > complicated, but It simply means you resubmit the changes that were > > reverted, on a suitable branch. Usually this is easy, unless there > > have been conflicting commits in the mean time. > > The problem in this case is that reverting the revert appears not > sensible for a repository that is supposed to then generate pull > requests to the mainline :-(( And using a branch branch for feature > development is not a good idea with Mercurial. :-((( > Couldn't you just package up all your changes and reapply (all at once or individually) on the current tip? > I think the question here is whether this situation merits some form of > rewriting history on a published repository. > > Clearly it is simpler and easier to annoy SCons_T_Tooling users than > SCons users, and I can see a way of achieving the needful by exporting > the diffs rather than the changesets and reapplying them to a new fork > of the mainline. The problem is though that there may still be conflicts > trying to reapply the resultant changesets to the mainline due to the > backout commit. > > Overall, I think the simplest thing to do here is to rewrite SCons > history to remove the D commit and backout and make sure everyone with > write authority retools themselves to avoid recommitting the D-related > bits. OK this will annoy anyone with a SCons fork, but I think it may be > better to do that than leave the problem in the repository. If we need to do this, here is how: http://stackoverflow.com/questions/9627964/how-can-i-completely-replace-a-bitbucket-repository-with-another-repository -- Gary
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
