[Scons-dev] Mercurial and the current SCons workflow are incompatible?

[Thomas Berg]

Hi,

On Sun, Oct 14, 2012 at 12:32 PM, Russel Winder <russel at winder.org.uk> 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)