Skip to main content

Renaming a commit with Mercurial before pushing

Posted by fabriziogiudici on September 3, 2009 at 8:16 PM PDT

A quick and short tip for Mercurial, just an excuse for testing Scribefire with the new Java.Net platform.

You have previously seen my posts praising the possibility of working in asynchronous fashion with Mercurial. In short, you can commit while disconnected, and push a batch of commits when you're connected again.

Now, there's a (small?) issue. When you commit some changes, it's a good practice to put into the commit message a reference to the issue you're working at - I mean precisely the Jira (or such) issue code, such as JRW-123. This is useful because there are many ways to integrate a source code repository with Jira, so the issue in Jira gets some comments (or even explicit links) to the commit into the repository.

Problem: if you're disconnected and performed a major refactoring that you want to document in Jira, how do you get the issue number? You can't, and it seems you have to postpone the commit, waiting to have the connection back, so you can enter the issue in Jira and get the issue code. Such a case happened to me today as in the afternoon I did a major refactoring in jrawio, changing the name of two packages, but I forgot the internet connection dongle at home. Mercurial async mode jeopardized?

Not at all. This afternoon I committed as usual, without putting any Jira reference in the comment:

fritz% hg commit -m "Renamed it.tidalwave.imageio.raw :  ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw :  ...rawprocessor.craw."
fritz% hg log --limit 1
changeset:   716:eedbe5086905
tag:         tip
user:        fabriziogiudici
date:        Thu Sep 03 15:49:13 2009 +0200
summary:     Renamed it.tidalwave.imageio.raw to ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw to ...rawprocessor.craw.

When I got back home twenty minutes ago, I connected to Jira and filed the enhancement, so I got the issue code (JRW-260). Then I made a local clone of the Mercurial repository, just to be safe (to avoid losing the commit in case of erroneous operation):

fritz% cd ..
fritz% hg clone src rename
updating working directory
361 files updated, 0 files merged, 0 files removed, 0 files unresolved
fritz% cd rename

So I'm now working in the "rename" clone. Now I'm going to the Mercurial Queues Extension (mq) (read my previous posts, it must be enabled in the Mercurial configuration): it's a set of commands that allow to turn some changesets in patches, that can be manipulated in many ways, and then converted back into commits. I've previously pointed to a Martin Fowler example using mq - what I'm doing is simpler than Martin's example, but I'm giving you some more information about what happens, so you can peek your nose behind Mercurial's scenes.

The first thing to do is to turn the commit into a patch (note that I specify what commit I need to work on: from changeset 716 to the 'tip'):

fritz% hg qimport -r 716:tip
fritz% hg log --limit 1
changeset:   716:eedbe5086905
tag:         qtip
tag:         716.diff
tag:         tip
tag:         qbase
user:        fabriziogiudici
date:        Thu Sep 03 15:49:13 2009 +0200
summary:     Renamed it.tidalwave.imageio.raw to ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw to ...rawprocessor.craw.

With the qrefresh command I can change the commit message:

fritz% hg qrefresh -m "Renamed it.tidalwave.imageio.raw : ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw : ...rawprocessor.craw (JRW-260)".
fritz% hg log --limit 1
changeset:   716:42aea5acc475
tag:         qtip
tag:         716.diff
tag:         tip
tag:         qbase
user:        fabriziogiudici
date:        Thu Sep 03 15:49:13 2009 +0200
summary:     Renamed it.tidalwave.imageio.raw to ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw to ...rawprocessor.craw (JRW-260).

Note that the timestamp is still the original one (my local time is about 21:46). The hashcode of the changeset, on the contrary, has changed. Now I can revert the patch into a commit:

fritz% hg qfinish -a
fritz% hg log --limit 1
changeset:   716:42aea5acc475
tag:         tip
user:        fabriziogiudici
date:        Thu Sep 03 15:49:13 2009 +0200
summary:     Renamed it.tidalwave.imageio.raw to ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw to ...rawprocessor.craw (JRW-260).

The situation is now just as the start of the operation, but the commit message has been changed. The next step is to push the change back to my main local repository (recall that I've been working in a safety clone):

fritz% hg push
pushing to /Users/fritz/Projects/jrawio/src
searching for changes
note: unsynced remote changes!
adding changesets
adding manifests
adding file changes
added 1 changesets with 75 changes to 197 files (+1 heads)

Then I move to the main local repository and see what's happening:

fritz% cd ../src
fritz% hg out
comparing with https://kenai.com/hg/jrawio~src
searching
for changes
changeset:   715:9db432fd34a5
user:        fabriziogiudici
date:        Thu Sep 03 14:11:23 2009 +0200
summary:     Fixed logging.

changeset:   716:eedbe5086905
user:        fabriziogiudici
date:        Thu Sep 03 15:49:13 2009 +0200
summary:     Renamed it.tidalwave.imageio.raw to ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw to ...rawprocessor.craw.

changeset:   717:42aea5acc475
tag:         tip
parent:      715:9db432fd34a5
user:        fabriziogiudici
date:        Thu Sep 03 15:49:13 2009 +0200
summary:     Renamed it.tidalwave.imageio.raw to ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw to ...rawprocessor.craw (JRW-260).

Note that the change (717) has been added to the repository as a new head (it has 715 as the parent, just as 716) and we still have the changeset 716. We don't need it any longer, so we can strip it:

fritz% hg strip 716
127 files updated, 0 files merged, 21 files removed, 0 files unresolved
saving bundle to /Users/fritz/Projects/jrawio/src/.hg/strip-backup/eedbe5086905-backup
saving bundle to /Users/fritz/Projects/jrawio/src/.hg/strip-backup/eedbe5086905-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 197 changes to 197 files

and then update the working space:

fritz% hg up -C default
197 files updated, 0 files merged, 21 files removed, 0 files unresolved

Now the situation is:

fritz% hg out
comparing with https://kenai.com/hg/jrawio~src
searching
for changes
changeset:   715:9db432fd34a5
user:        fabriziogiudici
date:        Thu Sep 03 14:11:23 2009 +0200
summary:     Fixed logging.

changeset:   716:42aea5acc475
tag:         tip
user:        fabriziogiudici
date:        Thu Sep 03 15:49:13 2009 +0200
summary:     Renamed it.tidalwave.imageio.raw to ...imageio.craw, it.tidalwave.imageio.rawprocessor.raw to ...rawprocessor.craw (JRW-260).

So I can finally push the changes:

fritz% hg push
pushing to https://kenai.com/hg/jrawio~src
searching
for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 198 changes to 198 files

You see that there are 2 changesets, since I had a previous commit unrelated with our operations.

Too complex, just to rename a commit message? Maybe. For sure, it would be nice that the IDE took care of all this, since from the UI perspective it would be just a matter of editing a text message. But in the end it's not so hard, and if you get confident enough with Mercurial to avoid working in a safety clone, you can skip many of the above operations.

Related Topics >>