How to fix an error in a Mercurial changeset comment?

Question

Is there a way to rewrite the hg commit message if the wrong information was entered? We always include our Bug ID when we commit a changeset. For instance:

hg commit -m "Bug 14585: LastName field should be mandatory"

But If I put the wrong bug ID, is there a way (through an extension maybe) to fix the comment once the changeset has been committed and pushed to a central repo?

Answer 1

If you haven't done anything else to your repository, you can do an "hg rollback" and just re-commit.

Answer 2

Changesets in Mercurial are deliberately immutable. If you have committed since that, no, you can't change that revision's files. However, there is a guide to edit the history, but take very, very very good care to not screw up your repo in the process.

It seems like you just want to edit the commit message, which you may be able to do.

Answer 3

The histedit extension might be what you are looking for. It allows you to edit commit messages after the fact. It also allows you to drop or fold revisions, much like git rebase --interactive.

Note that you have to enable and use the extension on the repo you'd like to fix; there is no way to edit the history of a remote repo. Additionally, I'd be very cautious about using this on a central repo. As Tim Post points out, mercurial changesets are not meant to be changed.

Answer 4

I found a way to fix a commit message IF the incorrect changeset is still the tip of the repo.

Suppose changeset 24 has an invalid comment. Also suppose that file1.txt was involved in that changeset. You can commit a fake change to file1.txt and then collapse the fake changeset with the incorrect changeset and provide a new message.

cd centralrepo
echo  >> file.txt
hg commit -m "fake commit"

hg collapse 24:25 -m "Bug 14555: LastName field should be mandatory"

It's a hack but it does the job and leaves to trace of the correction. It would probably not be too hard to create an extension to do that and turn this into an easy to use solution.

Answer 5

Options if it's too late for rollback

If rollback & re-commit isn't an option, then you have a couple of options, depending on how far the changes have propogated and how far back the changeset is.

I have used both of these methods in the past.

Fix with a sibling branch and deprecate/strip the old one

If it is only a few changesets, you could export those changesets as patches and re-apply them to the parent. For the first changeset (the one whose history you want to change) you will need to use hg patch --no-commit, and then hg commit with the new message. Then for the rest, just use hg patch to import the changes and the commit message as-is.

The problem with this method is that you end up with two branches, one of you need to ignore forever (I would update to the faulty changeset and tag the branch as deprecated).

Alternatively, you need to find every repository which contains this branch and hg strip it. The problem here is that some machines might not have the Mercurial Queues extension enabled and if you miss even one repo, and that repo is synced with another, the changes start to re-propogate.

Fix with a child branch and merge in subsequent changes

If the changeset has already propogated too far, you could try updating to the affected revision, forcing a dummy commit and in that commit message, explain what was wrong with the previous commit message. This changeset can then be merged with your current branch tip to bring everything up to date.

For instance, if the incorrect message was "Closes #5234" and it should have been "Closes #5324" then the child message could be "Uncloses #5234, Closes #5324".