Mercurial: Remove changeset from remote branch

Question

Is there a way to remove a from a remote changeset, or to remove an entire changeset? I accidentely pushed a .war file to a remote repo and I want to remove it.

Wafd

Answer 1

I used hg mqueue extension to edit history. It seems that it worked. Thanks all.

Wafd

ya, mercurial.selenic.com/wiki/EditingHistory lets you go back in your revisions and delete individual revisions or make changes (remove passwords) in your revisions – Pomatum

Answer 2

Mercurial tries very hard to keep your data safe, so you can generally not change history.

That being said, there are numerous extensions for Mercurial that allows you to quite easily change history anyway. There is a page on the wiki about editing history. That page also explains the consequences.

In your specific case, you have to ask yourself if others will have already pulled your changeset? If so, then even if you remove it, it will still exist in their clones and you might be better off with accepting the mistake.

If you decide to remove it, I suggest using hg clone to get a copy without it. This is the safe way since it will always leave behind a backup. If you pushed [z] to the remote repository:

[x] --- [y] --- [z]

and now want to remove it, then log into the server and do

hg clone -r y repo repo-without-z

Then repo-without-z will contain all changests up till [y] — that is, [z] will have been removed:

[x] --- [y]

You can then continue working and push a new changeset:

[x] --- [y] --- [w]

If I had pulled the [z] changeset already and now pull [w] I will see two heads in the repository:

            [w]
           /
[x] --- [y] --- [z]

This is not dangerous per se -- but people might be surprised. If I remove [z] from my clone I will end up with the same repository as you. But, as wrote above, this might be impractical if you have many users.

You can also use the MQ extension to strip the changeset away in-place. That way you wont make a new clone.

Finally, if you're certain that the push was the very last operation done on the server, then hg rollback can be used to remove the last transaction. But don't do this if you are the only one who can push to the repository, otherwise you might end up rolling back a different transaction.

If the repository is on Bitbucket, then you cannot log into the server. But Bitbucket has recently added a strip functionality to its web interface. Look for "Repository management" in the "Admin" section.

Southing

Thanks for your post. I am indeed using bitbucket, I was trying to remove a commit from the bitbucket repo, but it seems that it is not possible. Even using strip, bitbucket tells me that I'm occupying alot of space (because of the war I uploaded). – Wafd

Yeah, Bitbucket makes a backup of the stripped revisions, and the backup counts towards your quota :-( You can delete the repository on Bitbucket, create it again with the same name, and push from your local clone. – Southing

My comment above is no longer valid, please see Jesper's answer below. – Southing

Answer 3

Bitbucket does offer you a bundle (backup) upon stripping, and this does not count against your quota. The reason why it appears to do so, is only because we haven't invalidated the cache key specifying how much space you use.

This is a bug in our system, and will be remedied. Until then, rest assured that the changeset has been removed, and the backup is free :-)

Compliant

Answer 4

I had a similar case where i want to remove a merged branch "A" changeset from "Dev" branch remotely using TortoiseHg:

1. Create branch AA from branch A's parent branch; its origin.
2. Merge A into AA (working directory) and make sure that option: "Discard all changes from the other revision" is checked.
3. Merge AA into Dev branch (with a commit message indicating that branch A changes were removed).

You'll see that branch A changes are no longer exist in Dev.

Vulcanism

This worked for me, great solution. I would just clarify that for (2), I think you mean "merge A into AA" and discard. That's what I did anyway, and then step 3 created a nice commit which backed out all the unwanted changes. – Hefter