Is there any way of deleting a branch that has been pushed to a repo shared by all developers?

I have accidentally pushed a branch to a repo. Is there anyway I could alter the repo ( and remove the branch )? Closin开发者_JAVA百科g it is not a solution.

You got a couple of options, none of them easy, and none of them will leave you with a "phew, saved by the bell" feeling afterwards.

The only real way to fix this problem is to try to avoid it in the first place.

Having said that, let's explore the options here:

1. Eradicate the changesets
2. Introduce further changesets that "undo" the changes

The first option, to eradicate the changesets, is hard. Since you pushed the changesets to your central repository, you need direct access to the repositories on that server.

If this is a server where you don't have direct access to the repositories, only through a web interface, or through push/pull/clone, then your option is to hope that the web interface have methods for eradicating those changesets, otherwise go to option 2.

In order to get rid of the changesets, you can either make a new clone of the repository with the changesets, and specify options that stop just shy of introducing the changesets you want to get rid of, or you can use the MQ extension and strip the offending changesets out.

Either is good, but personally I like the clone option.

However, this option hinges on the fact that any and all developers that are using the central repository either:

1. Have not already pulled the offending changesets from the central repository.
2. Or are prepared to get rid of said changesets locally as well.

For instance, you could instruct all your developers to kill their local clones, and reclone a fresh copy after you have stripped away the changesets in the central repository.

Here's the important part:

If you cannot get all developers to help with this, you should drop this line of thought and go to option 2 instead

Why? Because now you have two problems:

1. You need to introduce barriers that ensure no developers can push the same changesets onto the server again, after you got rid of them. Note that relying on the warning by the server to prevent new branches being pushed is perhaps not good enough, as developers might have branches of their own they want to push, and thus not notice that they'll be pushing yours as well.
2. Any work any developer has done based on any of the offending changesets must either be rebased to a new place, or eradicated as well.

In short, this will give you lots of extra work. I would not do this unless the offending changesets were super-critial to get rid of.

Option 2, on the other hand, comes with its own problems, but is a bit easier to carry out.

Basically you use the hg backout command to introduce a new changeset that reverses the modifications done by the offending changesets, and commit and push that.

The problem here is that if at some point you really want to introduce those changesets, you will have to fight a bit with Mercurial in order to get the merges right.

However, there will be no more work for your fellow developers. The next time they pull, they'll get your correction changeset as well.

Let me just restate this option in different words:

Instead of getting rid of the changesets, keep them, but introduce another changeset that reverses the changes.

Neither option is good, both will generate some extra work.

We've ran into a similar problem once, when we had to remove a branch from the server repo from which all devs regularly pull. Backout wasn't an option because the problematic branch had already been pulled by everyone.

We stripped (hg strip from the MQ extension) the branch in the server repo. From now on, if a developer tried to push, he had a message “push creates new remote branches”, even though they didn't actually created any. We created a batch file with the strip command, distributed it among the devs and explained the “new remote branches” is a signal to run the batch file.

This approach takes some time and effort before everybody gets rid of the branch, but it works.

If the 'backout' option described in Jason's comment above doesn't do it for you, you can remake the repo up until the point of your mistaken push using hg convert, which (despite its name) also works with hg.

eg hg convert -r before-mistaken-push /path/to/original /path/to/new

You might have to play with the usebranchnames and clonebranches settings.