Hi, On Sun, Oct 14, 2012 at 12:32 PM, Russel Winder <[email protected]> wrote: > To backout, Mercurial doesn't remove a changeset (which is what Git > does), it adds a new changeset undoing the commit. This means that I can > no longer merge the mainline tip into the D_Tooling fork to ensure a > good pull request in the future, since that will just delete all the D > tooling support. > > I am assuming then I have to take a new fork of mainline and reimpose > the change sets over the backout to create D tooling fork – which as a > workflow completely sucks. Not to mention adding more and more replica > commits to the repository. Given what is possible with Git, this > situation with Mercurial really sucks.
The equivalent thing is just as problematic in git: if you "revert a merge" (using "git revert"), and make the change public, the same thing happens: you have not "undone" the merge, but instead created a new changeset that undoes everything that was delivered in the merge. The only difference with git is that it is easier to rewrite the history to delete the entire merge commit from history, using 'git reset' or 'git rebase' for example (which you normally wouldn't do when the history is public). At my dayjob we use Perforce, and since this is a fundamental problem (independent of SCM, as long as the merge algorithm is similar) we 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. - Thomas (scons and git user) _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
