HgBan

A mercurial extension to ban specific changesets from a repository.

Contents

Status
Overview
Configuration
Setting up the .hgban file
Format of the .hgban file
What does a user do if changesets are rejected
See also

1. Status

This extension is not distributed with Mercurial.

Author: Jason Harris and Angel Ezquerra

Repository: https://bitbucket.org/jfh/hgban

Web page: https://bitbucket.org/jfh/hgban/wiki/Home

2. Overview

This extension can be used to ensure that certain changesets which are determined to be "bad" by a team can be banned from being repushed to a central repository.

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 hgban is intended to prevent such a re-push of these "bad" changesets.

3. Configuration

Configure your .hgrc to enable the extension by adding following lines:

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

4. Setting up the .hgban file

Once the extension is enabled on the central server, to ban / interdict / bar changesets simply create a file named '.hgban' at the root level of the repository and add line-by-line the changeset hashes that are to be banned. You can commit the .hgban file to the repo if you want but it is not necessary.

5. Format of the .hgban file

The .hgban file is examined line by line by the hgban 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

6. 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:

Read any messages from the person who specifically interdicted the changesets.
Determine in your local repository if you have committed anything on top of these bad changesets.
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 rebasing, transplant, or MQ. (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.)
Locally use 'hg strip' to get rid of the bad changesets and their descendants.

See editing history and in particular rebasing and transplant