By default, grails uses ~/.grails as the working directory. If you’re doing branchy development, you can run into problems with this if you’ve got plugins installed in one branch that aren’t in the other. Having a unique directory per branch prevents you from having to run grails clean all the time.

Here’s a quick shell script that changes the grails working directory to have the branch name as a suffix if your source is contained in a mercurial repository (ex: the default branch would be ~/.grails_default and the 1.0 branch would be ~/.grails_1.0). If your application is not in a repo, it just uses the regular ~/.grails directory.

#!/bin/sh
HG_BRANCH=`hg branch 2>/dev/null`
GRAILS_SCRIPT=$GRAILS_HOME/bin/grails
 
if [ $HG_BRANCH ]; then
	GRAILS_WORK_DIR=`echo ~`/.grails_$HG_BRANCH
	echo "** grails working directory: $GRAILS_WORK_DIR"
	$GRAILS_SCRIPT -Dgrails.work.dir=$GRAILS_WORK_DIR $@
else
	echo "** default grails working directory"
	$GRAILS_SCRIPT $@
fi

Just save this script as “grails” and put it in your PATH before the $GRAILS_HOME/bin directory (also make sure that you’ve defined $GRAILS_HOME). I have a ~/bin directory that’s the first thing in my PATH.

If you use the grails-debug command, you can repeat these steps for that, just change GRAILS_SCRIPT to $GRAILS_HOME/bin/grails-debug.

This same technique could easily be modified to be used for other source control systems such as git or subversion.

I’ve made some enhancements to them in the interim that have made them even easier to use.

The most important alias is gtaf, which is short for “grails test-app” for failed tests.

It will search through your test output directory and look for any tests that failed. If it finds any, it will rerun only those tests. Otherwise, it will rerun all tests. That makes it easy to just use gtaf all the time. If any tests fail, it will open them up using Console.app.

If you’re not on OSX, or would like to use something else to view the failed test logs, just modify the testlog alias to do something different.

There are alternative versions of it to only run failed integration tests (gtaif – Grails Test App Integration Failed), failed unit tests (gtauf – Grails Test App Unit Failed) or attach a debugger to the tests as they run (gtadf – Grails Test App Debug Failed).

These aliases, plus most of the rest of my zsh setup, is available on bitbucket. If you haven’t used zsh before and are still using bash, I suggest switching over for the numerous benefits that it gives you.

Here’s the section of zshrc_general that has the grails testing aliases, just add this to your .zshrc/.bashrc and make sure to uncomment the appropriate GRAILS_TEST_LOG_DIRECTORY export if you’re not running grails 1.2 yet:

# grails > 1.2
export GRAILS_TEST_LOG_DIRECTORY=target/test-reports
 
# grails < 1.2
# export GRAILS_TEST_LOG_DIRECTORY=test/reports
 
# after grails-test if there were ERROR messages, you can open those logs with the Console.app using this
alias testlog='for F in `grep -lE "FAILED|Caused\ an\ ERROR" $GRAILS_TEST_LOG_DIRECTORY/plain/*.txt`; do echo ">>> opening" $F; open -a Console $F; done;'
 
# grails-debug-suspend doesn't exist by default, it's a copy of grails-debug with the suspend flag changed to "y" so that
# we can attach a remote debugger before it proceeds past startup
 
# aliases where you can optionally pass in a set of tests to run (or no argument to run all tests in that group)
alias gta=grailsTestApp
alias gtad=grailsTestAppDebug
alias gtau=grailsTestAppUnit
alias gtaud=grailsTestAppUnitDebug
alias gtai=grailsTestAppIntegration
alias gtaid=grailsTestAppIntegrationDebug
 
# aliases that will rerun any failed tests (or all tests if there aren't any failed tests)
alias gtaf=grailsTestAppFailed
alias gtadf=grailsTestAppDebugFailed
alias gtauf=grailsTestAppUnitFailed
alias gtaudf=grailsTestAppUnitDebugFailed
alias gtaif=grailsTestAppIntegrationFailed
alias gtaidf=grailsTestAppIntegrationDebugFailed
 
 
function grailsTestApp() { grailsTest grails "" $1 }
function grailsTestAppFailed() { grailsFailedTests grails "" }
 
function grailsTestAppDebug() { grailsTest grails-debug-suspend "" $1 }
function grailsTestAppDebugFailed() { grailsFailedTests grails-debug-suspend "" }
 
function grailsTestAppUnit() { grailsTest grails -unit $1 }
function grailsTestAppUnitFailed() { grailsFailedTests grails -unit }
 
function grailsTestAppUnitDebug() { grailsTest grails-debug-suspend -unit $1 }
function grailsTestAppUnitDebugFailed() { grailsFailedTests grails-debug-suspend -unit }
 
function grailsTestAppIntegration() { grailsTest grails -integration $1 }
function grailsTestAppIntegrationFailed() { grailsFailedTests grails -integration }
 
function grailsTestAppIntegrationDebug() { grailsTest grails-debug-suspend -integration $1 }
function grailsTestAppIntegrationDebugFailed() { grailsFailedTests grails-debug-suspend -integration }
 
function grailsFailedTests() {
	FAILED_TESTS=''
	for F in `grep -lE "FAILED|Caused\ an\ ERROR" $GRAILS_TEST_LOG_DIRECTORY/plain/*.txt`; do
		FAILED_TESTS="$FAILED_TESTS `echo $F | sed -E 's/.*TEST-(.*)Tests.txt/\1/g'`"
	done;
	echo "failed tests: $FAILED_TESTS"
	grailsTest $1 $2 $FAILED_TESTS
}
 
function grailsTest() {
	echo "Running: $1 test-app $2 $3 || testlog "
    time $1 test-app $2 $3 || testlog
}

I believe that they’ll also work fine as-is in bash, though I haven’t tested them.

Whenever she’d try to print, the job would say “On Hold: Authentication Required”. After some fiddling around I found a solution:

1. Go into System Preferences and go to the Print & Fax panel.
2. Right click on the printer and choose “Reset Printing System…”. This will remove all of your printers.
3. Hit the “+” and add the printer back, it should now be reset and have fixed whatever was fubar before.
4. Click on the “Sharing Preferences” button (or go to the “Sharing” System Preference panel)
5. Make sure that “Printer Sharing” is checked and that your printer’s name is also checked and that “Everyone” is set to “Can Print”
6. On the remote machine you want to remove the printer and add it back in through the System Preferences Print & Fax panel

(This is on 10.6.1, not sure if this works in 10.6.0 (where I first had the problem), you should update to the latest).

After doing all that, I was able to print from my remote computers without any problems or any issues around authentication.

Combining the unix “watch” command with the mysql “show processlist” command gives me what I’m looking for. A quick, self-updating status of the current state of the database.

watch -n 5 --differences "mysql -u username -psekrit -e 'show processlist'"

Shows something like this:

Every 5.0s: mysql -n 5 -u username -psekrit -e 'show processlist'                                   Thu Jun 18 05:25:14 2009
 
Id      User    Host       db      Command Time    State         Info
3141    admin   localhost  mydb    Query   34978   freeing items SELECT id, type, active, email FROM user WHERE email
3146    admin   localhost  mydb    Sleep   0                     NULL       
24876   root    localhost  NULL    Query   0       NULL          show processlist

Where the “time” column is the number of seconds the query has been running, and Info holds the actual query (you can use “show full processlist” to see the full query).

Watch is a nice little linux util that runs a command every “n” seconds (it defaults to 2 seconds). If you use the –differences switch, it will highlight the differences between one update and another. I use watch for all kinds of monitoring activities, such as watching a directory to see a file grow in size as it gets transfered.

Here’s a quick shell function that you can add to your .bashrc/.bash_profile/.zshrc to use on arbitrary hosts:

function mysqltop() {
    MYSQL_OPTS=$@
    watch -n 5 --differences "mysql $MYSQL_OPTS -e 'show processlist'"
}

Then just pass in any creds/host info you need like a normal mysql command:

mysqltop -u ted -psekrit1 -h example.com -P 3307

If you’re on linux, you probably already have “watch” installed. If you’re on OSX, you probably don’t, but you can get it quickly through macports. Install macports, make sure “port” is in your path and run:

sudo port install watch

There is also a command called mytop that you can get which looks like the same thing, but prints out the processlist details with some nicer formatting and a little extra information. It’s in macports, but it has a number of dependencies including mysql so if you didn’t install mysql through macports, you might want to stick with what I have above or get it another way.

(EDIT: updated with bash function)

I found it painful to manually eject each individual drive in the finder so I threw together this quick AppleScript to eject all the disks.

tell application "Finder"
	eject (every disk)
end tell

Just open up /Applications/AppleScript/ScriptEditor.app and paste that in. Then choose “Save As” and pick “Application”. That will compile the script and create a .app file that you can click on to run, or you can put it in your path and execute it there.

I think the same kind of script could be created with the command line “diskutil eject” command, but this seemed cleaner as I wasn’t able to come up with a generic way to figure out which disks were “ejectable” and which weren’t. AppleScript is able to figure that all out for you.

I’ve created a new bitbucket repository to hold my shared zshrc configuration. You can get it for yourself by cloning the repository:

cd ~
hg clone http://bitbucket.org/tednaleid/shared-zshrc/

If you don’t have mercurial installed, you can just grab the compressed archive of your choice from the downloads page.

I’d suggest cloning/unzipping into your home directory, but you can put it wherever you want.

There’s an install.sh script in there that will create a new ~/.zshrc file. If you have an existing .zshrc file, just move it out of the way and run the install script (it won’t let you whack an existing file).

./install.sh

That created .zshrc file will load up all of my shared settings and aliases from wherever you have the shared-zshrc directory. It also will look for a host specific file where any sensitive info, or host dependent info can be added. I normally put things like my change directory and ssh aliases in here.

I probably created around half of these files myself, but I couldn’t tell you for the life of me where the majority of the other half came from. This file has accreted over the years like barnacles on a ship.

Some of these commands originally started out in either a tcsh file (or was it ksh?), I eventually moved to bash, and then a couple of years ago, a coworker showed me the wonders of zsh and I haven’t looked back.

If you’re still using bash, give zsh a try. Changing your shell is as easy as running this command:

chsh -s /bin/zsh

ZSH Specific Stuff

Most of the zsh shell configuration magic is in zshrc_compinstall. Some features include:

• shared history across shells
• command spelling correction
• vastly improved tab completion of commands (including keyboard navigation of potential matches)
• file globbing that makes finding files easy (try ls **/*.txt to recursively search for all txt files, much easier than find . -name "*.txt"
• automatically using pushd for cd commands, use “dh” to see a history of your directories, use cd -N to go back N directories in your history (ex: cd -3)

Useful Aliases

Some of the most useful aliases in zshrc_general include:

Grep through Aliases (ag)

I often forget what some of my less often used aliases are, but I know what commands they use. I’ve set up “ag” (alias grep) to help me search through my aliases and find the right one:

% ag python
webshare='python -m SimpleHTTPServer'

Grepping History (gh)

Great for finding commands in your history that you can only remember part of.

  gh grails
  ...
  582  grails create-app testDates
  584  grails create-domain-class Foo
  585  grails generate-all Foo
  587  cd grails-app
  591  grails generate-views Foo
  592  grails run-app

Global Alias – GV – to “grep -v”

Grep is great for finding things, but often you find too much and need to slice stuff out. If you use “grep -v” that finds all lines that don’t match a pattern. The global alias “GV” that makes this even easier.

   grep -ri foo

If that finds too much stuff (say catalina log files and svn files that you don’t care about), just slice them out with GV:

   grep -ri foo GV svn GV catalina

That will remove any lines that have “svn” or “catalina” anywhere in them (including the file name).

I think that rc files tend to be very personal things, what works for me likely won’t work for you exactly as it is. But I also love to look at other people’s rc files to grab the things that look interesting. Feel free to poke through mine and grab whatever strikes your fancy.

There’s a ton of other stuff in there that I use every day, including sections specific to version control (svn and hg) as well as groovy/grails shortcuts. Feel free to poke around and ask me any questions about what something does.

This is what I was seeing:

% curl -k https://www.google.com
curl: (1) Protocol https not supported or disabled in libcurl

After a bunch of fiddling around looking at the Portfile (located at /opt/local/var/macports/sources/rsync.macports.org/release/ports/net/curl/Portfile), I saw that there was something called a variant that seemed to talk about ssl support.

I’d never needed to install a variant of a port before, but it’s actually pretty easy to do. Just add a “+” with the variant name at the end of the install command.

sudo port install curl +ssl

After that, curl did exactly what I was expecting it to:

% curl -k https://www.google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com">here</A>.
</BODY></HTML>

So if you’ve already got curl installed with macports, you’ll probably want to uninstall it, then clean to be sure, then reinstall with the variant name:

sudo port uninstall curl
sudo port clean curl
sudo port install curl +ssl

From the documentation, it appears that it also works for the upgrade command as well, so I believe you could force an upgrade and get it to install the curl ssl variant with:

sudo port -f upgrade curl +ssl

I haven’t tested this though, so I can’t say with 100% certainty that it will work.

UPDATE: Brian Michelich tried this and ran into some issues because he had git-core installed through macports. Git-core relies on curl so forcing an upgrade could potentially bork anything that relies on curl. The safest thing is likely to uninstall curl as macports will let you know if anything relies on it before you remove it.

If you want to check if you have any dependencies, you can use the “dependents” command:

port dependents curl

I hope this helps someone (possibly me, in 6 months when I’m setting up my next computer :).

function switchGrails() {
    echo "Switching to groovy version: $1"
    echo "Switching to grails version: $2"
    sudo rm /usr/local/{groovy,grails}
 
    sudo ln -s /usr/local/$1 /usr/local/groovy
    sudo ln -s /usr/local/$2 /usr/local/grails
    echo "Done!"
    ls -latr /usr/local/{groovy,grails}
}
 
alias g104='switchGrails "groovy-1.5.7" "grails-1.0.4"'
alias g11rc2='switchGrails "groovy-1.6.0" "grails-1.1-RC2"'

You can create your own aliases like the ones above to switch to the groovy/grails combinations that you happen to be working with.

Just stick the code above in your .profile/.bashrc/.zshrc file and restart your shell to make the aliases available.

This function assumes that you’ve got you’ve got groovy and grails installed in your /usr/local directory and that you use a symlink at /usr/local/groovy that $GROOVY_HOME is pointed to and /usr/local/grails that $GRAILS_HOME is pointed to. If those assumptions aren’t correct for you, you’ll have to tweak the script.

It also uses “sudo” as it assumes that /usr/local is owned by root and not by your logged in user. If you’ve chowned the directory to yourself, you can remove the sudo (and the need to enter your password).

Now it’s easy for me to switch between different projects by just typing the appropriate alias:

pollux% g104
Switching to groovy version: groovy-1.5.7
Switching to grails version: grails-1.0.4
Done!
lrwxr-xr-x  1 root  wheel  23 Mar  8 19:55 /usr/local/groovy -> /usr/local/groovy-1.5.7
lrwxr-xr-x  1 root  wheel  23 Mar  8 19:55 /usr/local/grails -> /usr/local/grails-1.0.4
 
 
pollux% g11rc2 
Switching to groovy version: groovy-1.6.0
Switching to grails version: grails-1.1-RC2
Done!
lrwxr-xr-x  1 root  wheel  23 Mar  8 19:56 /usr/local/groovy -> /usr/local/groovy-1.6.0
lrwxr-xr-x  1 root  wheel  25 Mar  8 19:56 /usr/local/grails -> /usr/local/grails-1.1-RC2

The one problem with this script is that if the files already exist, a prompt will come up after ~10 seconds or so (after the grails environment bootstraps) asking you if you want to Overwrite everything:

grails generate-all "*" 
...
~10 seconds pass
...
Generating views for domain class Baz ...
File /foobar/grails-app/views/baz/list.gsp already exists. Overwrite?y,n,a

This was a bit of a pain as I’d often kick the script off, get distracted and then come back to the shell with that prompt still waiting for me to tell it what to do. I’d rather just start working with my shiny new scaffolding.

The easy solution to this is simply to pipe the answer you want into the grails command:

echo "a" | grails generate-all "*"

Doing that will pipe the “a” into the grails command so that when the prompt finally comes up, it knows that it can continue regenerating all of my scaffolding.

It seems simple enough after I figured it out, but I thought it could save some other people time when they’re hacking around with templates and know they want to regenerate all of them.

My home directory has a bin folder in it that’s continually getting new jigs added to it, and my zshrc file is an ever-expanding list of quick shell functions.

Recently, I’ve been doing a lot more work with Mercurial as the team that I’m on switched from Subversion a couple of months ago on our Grails project. The initial transition was a little difficult for some people, but I think just about everyone is pretty happy with the transition now that we’ve made it.

Something that has helped everyone get comfortable with more complex Distributed Version Control System like Mercurial has been the distribution of shims and jigs amongst the team. I thought these tips might be useful to others as well.

Configuring Mercurial

After installing mercurial (the easiest way is to just get the appropriate binary package for your OS), you’ll want to get it configured.

A good place to start is with someone else’s configuration file. Here’s my my current ~/.hgrc configuration file (with the username replaced):

[extensions] 
fetch=
extdiff=
color=
hgext.graphlog=
hgshelve=~/Documents/workspace/hgshelve/hgshelve.py
rdiff=~/Documents/workspace/rdiff/rdiff.py
hgext.mq =
 
[diff]
git = 1
 
[ui]
username = YOUR NAME <YOUR_NAME@YOUR_COMPANY.com>
 
[extdiff]
cmd.kdiff3 =
cmd.chdiff =
opts.chdiff = --wait
 
[merge-tools]
kdiff3.args = $base $local $other -o $output

In it, you’ll see a number of useful extensions, including:

• hg fetch – automates the pull/update working copy/merge/commit merge steps
• extdiff extension – Mercurial allows you to set up external tools to do diffs and merges. I’m using 2 different graphical merge tools for different purposes
• hg chdiff – Changes.app for just comparing two files in a diff. Changes is a beautiful shareware diff tool for the mac, it unfortunately doesn’t do a 3-way merge.
• hg kdiff3 – For merging, (and some diff situations), I need the power of a 3-way merge tool and I’ve found kdiff3 to be the best one that I’ve used. It’s an open source, free, cross platform 3-way merge tool. Using a 3-way merge tool is imperative for getting your merges correct.
• color extension – just colorizes some output including the status command
• hg glog – an ascii graphical log of the commit tree (enhanced “hg log”)
• hg shelve – simplified patch management that allows you to “shelve” changes without committing them locally, for instance if you want to do a fetch, I asked about this on Stack Overflow
• hg rdiff – remote diff, allows you to compare a file checked into your local repo with a file in the remote repository, I also asked about this on Stack Overflow
• mq extension – mercurial queues, a more advanced topic that I don’t think anyone else at my workplace uses, but there’s a lot of power in mqueue if you look into it. The Mozilla guys have a really nice introductory tutorial to using this plugin.

Setting up KDiff3 so you can do 3-way merges

The simplest way to get KDiff3 is to download the binary from the main website (click on the download link and then choose the binary appropriate for your platform).

For the mac, you’ll just get a zip file with a KDiff3.app file in it that you should drag to your /Applications directory. Then, you need to make sure that the actual executable in the application is in your path. I just create a symlink in my path to the executable inside the application package:

ln -s /Applications/kdiff3.app/Contents/MacOS/kdiff3 /usr/local/bin/kdiff3

You might not have /usr/local/bin in your path by default. If you can execute kdiff3 --help on the command line, you’re ready to go.

Setting up the “shelve” extension

The easiest way to get the shelve extention set up is to simply clone the project that holds the python script to your local filesystem:

hg clone http://freehg.org/u/tksoh/hgshelve/ hgshelve

Then just make sure that the path in your ~/.hgrc file points to the correct location of the hgshelve.py file in the cloned repository.

You can test that it’s working by just executing:

hg help shelve

If you don’t get an error message, it’s set up right and you can start using it.

Setting up the “rdiff” extension

Setting up the rdiff extension is similar to the shelve extension above. Just clone the repository:

hg clone -r c3ac1c497bf0 http://hg.kublai.com/mercurial/extensions/rdiff

We clone an older revision currently as the tip in that project uses some unsupported stuff that isn’t in mercurial 1.0.2, if you’ve got a newer version of mercurial, you might be able to get the tip of the rdiff extension and have it work.

Then make sure that your ~/.hgrc is pointed to the right path for the rdiff.py file in the repo you just cloned.

It’s a little quirky in that it actually modifies the existing “hg diff” command by detecting if the first parameter is a remote URL. If it is then it will diff that file against your tip file in your local repo (not the working copy). This as the remote repo is first in the arguments, it’s the reverse of what I’d expect, but you can pass “–reverse” to the hg diff command to switch that around.

I could see these being potential enhancements to the extension, but for now, I can work around them with a bash/zsh shell function in my startup file. It does a temp checkin of my working copy (held by the mercurial transaction so it can be rolled back), executes the reverse diff, and then rolls the transaction back to return things back to the way they were:

hgrdiff() {
    hg commit -m "temp commit for remote diff" && 
    hg diff --reverse http://my_hardcoded_repo $* &&
    hg rollback      # revert the temporary commit
}

And then call it with:

hgrdiff <filename to diff against remote repo tip>

Other Mercurial Jigs and Shims

Here are some other jigs and shims that I’ve found useful.

Jig to Get a List of Files With the Same Status

One jig that I’ve gotten a ton of use out of, is a modification to the normal “hg status” command. Normally, “hg status” returns a list of all files that are different in the working directory when compared to the tip if the repository. In the output of status, each file is printed with a character in the first column that signifies the status of that file. Ex:

% hg status
M build.xml
A src/groovy/Foobar.groovy
A src/groovy/Quux.groovy
? src/groovy/Bar.groovy
? src/groovy/Baz.groovy

Some of the most common statuses are:

• ? – not tracked, unknown to the source control repository
• M – modified, this file is different in the working copy than on the file system
• A – added, source control is aware of this file, but it hasn’t yet been committed
• R – removed, this file has been marked for deletion on the next commit
• ! – missing, this file is not present in the working copy but is in source control

Often, I’ll want to do something with all of the files in a particular status, but I can’t easily do that as they’re mixed in with the other file types. Also, the status flag at the beginning of the line prevents me from piping the status into another command.

I’ve come up with this shell function to allow me to filter lists of files (it actually works for subversion too, so there are 2 aliases). Just paste this into your bash/zsh startup file:

vcst() {
	# print out all of the files with a passed in status flag (M - modified, A - added, ? - unknown, etc) (default ?)
	# expects first parameter to be the version control command (likely svn or hg)
	STATUS='\?'
	if [ -n "$2" ]
	then
		STATUS=$2
	fi
	$1 status | egrep "^$STATUS" | awk '{print $2}'
}

alias svnst='vcst svn'
alias hgst='vcst hg'

Then you can use the “hgst” command to see all the files in a particular status, one per line. By default, it shows files that aren’t tracked (“?“), but you can pass a parameter that specifies another flag type if it’s other than “?“.

To see the list of files that aren’t in source control, just use:

% hgst
src/groovy/Bar.groovy
src/groovy/Baz.groovy

If you want to delete all of the files that aren’t in source control, all you have to do is send the results of that command to rm:

rm `hgst`
# removes src/groovy/Bar.groovy and src/groovy/Baz.groovy

If you want to edit all of the files that have been added in TextMate:

mate `hgst A`
# opens src/groovy/Foobar.groovy and src/groovy/Quux.groovy in TextMate

If you want to do a diff and see only the files that have been modified using kdiff3:

hg kdiff3 `hgst M`
# would show a diff of build.xml vs the working copy

Shim to See a List Incoming and Outgoing Files

When I’m about to push changes out to a remote server, or pull changes down from that server, I often want to know what files will be affected by this action. Surprisingly, there isn’t an easy built-in way to do this.

There is the hg incoming -v command, which will print out a log format of all of the different changesets. But I don’t really care about all the changesets, I just want to know which files will be affected. Here’s a sample run of incoming with 3 changesets:

% hg incoming -v
comparing with /Users/ted.naleid/temp/foo
searching for changes
changeset:   1:5c5f71bda234
user:        Ted Naleid <ted.naleid@carol.com>
date:        Tue Nov 25 20:30:51 2008 -0600
files:       src/groovy/Foobar.groovy
description:
initial commit of foobar.groovy
 
 
changeset:   2:fe4a615747af
user:        Ted Naleid <ted.naleid@carol.com>
date:        Tue Nov 25 20:31:36 2008 -0600
files:       src/groovy/Bar.groovy src/groovy/Foobar.groovy
description:
committing 2 files
 
 
changeset:   3:21e3d26bc3eb
tag:         tip
user:        Ted Naleid <ted.naleid@carol.com>
date:        Tue Nov 25 20:31:54 2008 -0600
files:       build.xml src/groovy/Baz.groovy src/groovy/Foobar.groovy src/groovy/Quux.groovy
description:
3rd commit of files

That’s not very useful as it’s hard to parse out the actual files in that list (and see only the unique list).

I use the following shim (just put in your bash/zsh rc file) to make this simple:

# look for lists of files in piped output, sort the unique set of them and print them one per line
lf() {
    egrep "^files:" | awk '{for (i=2; i<=NF; i++) print $i}' | sort | uniq 
}
 
alias ic="hg incoming -v | lf"
alias og="hg outgoing -v | lf"

Once this is installed, you can simply use the og (outgoing) or ic (incoming) aliases to see what you’ll affect if you actually do a push or a pull.

Here’s the output using the incoming shim on same changeset above:

% ic
build.xml
src/groovy/Bar.groovy
src/groovy/Baz.groovy
src/groovy/Foobar.groovy
src/groovy/Quux.groovy

That makes it quick and easy to see the real things that you’ll affect by your actions.

Enhancing Your Shell Prompt With Mercurial Info

A couple of other commands that I have in my zshrc (they should also work in a bash startup file):

hgtarget() {
    hg_root=`hg root 2>&1 | egrep -v "$abort:"`
   	if [ $hg_root ]; then
    	if [ -f $hg_root/.hg/hgrc ]; then
        	hg_target=`cat $hg_root/.hg/hgrc | egrep "^default =" | sed 's/\(^default = \(http:\/\/\)*\)\(.*@\)*//'`
        	echo "$hg_target"
        fi
    fi
}

hgbranch() {
	hg_root=`hg root 2>&1 | egrep -v "$abort:"`
	if [ $hg_root ]; then
		hg_branch=`hg branch`
		echo "$hg_branch"
	fi
}

These commands will tell you the path to the default push/pull target for your repository (hgtarget) as well as the current branch that you’re working on (hgbranch) in your repo.

I’ve added these to my shell prompt so that when I’m in a mercurial repository I’m more informed of the context that I’m working in. My prompt is a little complicated (lots more going on there besides this), but there are a number of good tutorials out there for modifying yours.