Home

HGBAN

A mercurial extension to ban specific changesets from a repository.

Use Case

Imagine that you have a team of people working on a mercurial repository. One of the members of the team pushes a changeset or group of changesets to the central repository but these changesets are "bad" for one reason or another. (Maybe some branch was merged when it should not have been, etc. Maybe some nuclear launch codes were accidentally committed, etc.). Ideally this should never happen. In practice it happens all too frequently.

So typically the leader of the project will send out an email saying something like: Please strip the following revisions from your repositories:

    162a93e027fdcc6f037c80d185eb201e346da0b0
    69cc2b0e47158d1a571a35ec89c5524b084944c9
    a4988662d998b8d986bdaec43079475827aa31d0

The problem is of course that in a team of say 20 people someone might have already pulled the "bad" revisions and they may accidentally miss the email, and re-push these bad revisions back to the central server.

The extension ban-changesets is intended to prevent such a re-push of these "bad" changesets.

Thus anyone who can change files on the server can simply add the above changeset hashes to the file repo/.hgban (creating this file if necessary) and if the ban-changesets extension is configured on the server, then none of the team can accidentally push any group of changesets which contain the changesets banned in the file repo/.hgban.

Enabling the Ban Changesets extension

The ban-changesets extension is enabled just like other mercurial extensions. Ie add something like the following to your ~/.hgrc file:

[extensions]
hgban = /path/to/hgban.py

Format of the .hgban file

The .hgban file is examined line by line by the ban-changesets extension. The changeset hash should start at the very beginning of the line. (Actually you can use general reveset syntax to specify multiple criterion for banning changesets.)

Thus the following is a valid .hgban file:

# Ignore these changesets due to bad branch merge
162a93e027fdcc6f037c80d185eb201e346da0b0
69cc2b0e47158d1a571a35ec89c5524b084944c9

# Ignore this changeset because it contains the nuclear launch code that Billy included
a4988662d998b8d986bdaec43079475827aa31d0

What does a user do if changesets are rejected

If you are trying to push some changesets to the server but the push is rejected because some of the changesets are banned from the repository, then likely you should:

  1. Read any messages from the person who specifically interdicted the changesets.
  2. Determine in your local repository if you have committed anything on top of these bad changesets.
  3. If you have committed stuff on top of these bad changesets then move your changesets to another part of the commit tree, using say 'hg export' and 'hg import', or using rebase, or using transplant, or the mq extension. (Now would likely be a good time to use 'hg clone' to make a "dummy" clone of the repository just in case you stuff up the history editing.)
  4. Locally use 'hg strip' to get rid of the bad changesets and their descendants.

See editing history and in particular rebasing, transplant and strip

Updated

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.