I think it still has some advantages over other solutions that have been posted:

• It completes long options (--trace, --execute-print, etc.).

• It falls back to completing filenames. I find this most useful for running just one set of tests, e.g.:

  $ rake test:units TEST=test/unit/
  bar_test.rb  foo_test.rb  helpers/

• It handles colons for namespaced tasks correctly, without resorting to setting COMP_WORDBREAKS globally.

• It doesn’t rely on an external script, which means it only has to fire up one Ruby interpreter (to run rake) instead of two (to run a Ruby completion script that runs rake).

It doesn’t cache the task list, so it still requires a call to rake --tasks on every <TAB>. I may add caching support later.

Here it is for your inspection and enjoyment:

LiveJournal peeps, I’m back.

Update 10 Oct 2009: Feed URLs are now redirected to their new locations.

Update: I’ve successfully built the mysql gem against MySQL installed via a 64-bit fink as described below. Here’s the incantation I used:

$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- \
    --with-mysql-dir=/sw64

        <span id="more-1373"></span>

        <h3>Updating Fink</h3>

Since I was upgrading from Leopard, I already had a 32-bit install in /sw. Following the upgrade instructions made what I already had work again. Updating my installed packages was another matter. Here’s the issues I ran into on a fink update-all, and how I solved them:

1. pango1-xft2-ft219 ran into some issues with missing .la files. The fix suggested on the fink-users list worked for me, although I can’t guarantee it won’t break something later.

2. boost1.35.nopython passes -Wno-long-double to GCC. The version of GCC in Snow Leopard doesn’t have that flag, and errors out if you try to use it. I fixed it by copying fink’s package info (boost1.35.info and boost1.35.patch) to the local/main package tree (/sw/fink/dists/local/main/finkinfo/), and fixing the patch to remove the -Wno-long-double option.

   The result is available on bitbucket. Just copy 32bit/boost1.35.* into the aforementioned local/main package tree on your fink install, run fink index, and then fink install boost1.35-nopython.

Installing a 64-bit Fink

Next up was getting my gems, in particular RMagick, working with Snow Leopard’s shiny new 64-bit Ruby. Since it’s 64-bit, you can’t build gems against your 32-bit libraries installed through fink. But no matter—it turns out to be possible (even relatively easy) to set up two fink installs, one 32-bit and one 64-bit. Here’s how to do it:

1. Follow the instructions from the fink website to bootstrap a 64-bit install into /sw64, leaving the existing 32-bit install alone.

2. Skip adding . /sw64/bin/init.sh to your login scripts, leaving the 32-bit install as the default. Instead, when you want to use the 64-bit version, execute that line from the terminal. Now just that terminal window will default to 64-bit fink.

Once I’d done the above, it was just a matter of running fink install imagemagick, and then sudo gem install RMagick… oh, but wait, no.

See, RMagick is picky about the configure options you use to build ImageMagick; it doesn’t work with HDRI support enabled (whatever that is). Fink’s imagemagick package has it enabled by default, so I again took to customizing the Fink package info and putting it in the local/main repository (in this case at /sw64/fink/dists/local/main/finkinfo/), changing --enable-hdri to --disable-hdri. Once again, the result is available on bitbucket in 64bit/imagemagick*.

So once I’d finished that, I ran fink index and fink install imagemagick again, and the RMagick gem installed fine. Yay!

My next endeavor will be to try to install a 64-bit MySQL thru fink, but for now I’ve handled that by installing the MySQL 5.1 package from mysql.com.

Also note: I haven’t tested any X11 apps under fink64 yet. Not installing the fink64 xinitrc might break things horribly.

I’ve been playing with hg-git for the past couple weeks off-and-on (Abderrahim Kitouni’s fork—and so should you). Today I decided to try to use it to provide git mirrors of my projects. It took a bit of futzing around to figure out how to set it up, but as you can see above, it’s smooth like buttah. Here’s how I did it.

        <span id="more-1366"></span>

        <ol>

$ wget http://samba.org/~jelmer/dulwich/dulwich-0.3.3.tar.gz
$ tar xvzf dulwich-0.3.3.tar.gz
$ (cd dulwich-0.3.3 && sudo /usr/bin/python setup.py install)


$ wget -O hg-git.tar.gz http://bitbucket.org/abderrahim/hg-git/get/tip.gz
$ (cd /path/to/hgext && tar xvzf /path/to/download/hg-git.tar.gz)

[extensions]
hg_git = /path/to/hgext/hg-git

git@github.com:krbullock/vlad-merb.git

git+ssh://git@github.com/krbullock/vlad-merb.git

[paths]
github = git+ssh://git@github.com/krbullock/vlad-merb.git

$ hg push github

Boom. Done.

Description:

Merb support for Vlad. Prior to 2.0.0, Vlad included support to make vlad:start and vlad:stop work with Merb; this plugin adds Merb support back in, and makes it a bit more robust.

Changes:

2.0.0 / 2009-09-05

• 3 major enhancements

  • Birthday!

  • Bring Merb support up to speed with recent versions of Merb.

  • Add deploy variables to run Merb as another user, and to be able to use sudo.

If you’re not using either Git or Mercurial (hg) (or Bazaar or some other appropriate DVCS), you should be. I prefer hg, but I think git is generally fine. Scott Chacon, however, thinks that git is unquestionably better than hg, for three specific reasons I intend to counter here, with reference to Geoffrey Grosenbach’s recent post on the matter.

Update 2 Sep 2009: See this post by Steve Losh for more on the branching issue.

Update 2 Oct 2009: Scott Chacon is not an idiot (nor did I mean to even imply that he was!), and has demonstrated his not-idiotness by apologizing “for being a tool” (his words).

        <span id="more-1325"></span>

        <ol>

I don’t mean to say that hg is better than git. It has its weaknesses as well—but these aren’t them.

I’ve taken over development of Mercurial support for Vlad, and with the latest release (2.0.0), it’s been split out into a plugin (along with Perforce support, with more to come). So, to get Mercurial support back, just

$ gem install vlad-hg

and continue to use your existing deployment recipes.

We’ll likely be moving vlad-hg from its own lonely home into the hitsquad RubyForge project, so Vlad and all its plugins will be available from the same location. Stay tuned.

The Ruby community, in my view, should welcome and include everyone who shares the hacker spirit. It should also continue, in the hacker spirit, to be edgy, playful, anti-corporate, and always in favor of freedom.

All of us being human, sometimes we’ll be edgy in ways, like the now-infamous CouchDB presentation, that make some members or would-be members of the community feel starkly unwelcome. When that happens, those of us who notice it should absolutely call it out, and I, like Nick, pledge myself to do so. Those of us who make the mistakes should learn from them, and I think Matt Aimonetti is doing so. (I’m not sure that DHH gets it yet.)

        <span id="more-1146"></span>

        <p>I won't summarize or analyze the specific issue with Matt's slides (Martin Fowler has <a href="http://martinfowler.com/bliki/SmutOnRails.html">done a good job of that already</a>, q.v., and quoted below), except to say this: the <strong>effect</strong> was that the pictures used, in the context of a room full of a hundred or more men and six women, reinforced some really icky cultural norms about power dynamics between men and women. <strong>It wasn't intentional,</strong> but it was real. From an anti-sexual-violence perspective, those are the same norms that, in the minds of some, make rape <a href="http://www.nytimes.com/2009/04/30/opinion/30kristof.html">not a serious enough crime to bother processing the evidence</a>.</p>

I say that to underscore the seriousness of the matter. I don’t say it to demonize Matt Aimonetti (or DHH). Any of us could have misjudged the interaction of imagery and context as Matt did, and the effect could’ve been racist, classist, homophobic or any number of other things instead of sexist (the effect, not the presenter). How we handle it as fellow members of a community sets the tone going forward:

How about a community where women are valued for their ability to program and not by the thickness of their skin? How about a community that edgily pushes new boundaries without reinforcing long running evils? Perhaps even a community where women reach equal numbers? —Martin Fowler

Although the presentation in question makes me sad, I’m frankly thrilled at the discussion that it’s sparked and how it’s been conducted. I’m glad to see other men in the community listening to what women are saying about it, understanding, and responding. (Incidentally, why don’t I regularly read any women Rubyists’ blogs?) Most of the dialog across Twitter and blogs has been pretty constructive. Some conflict and defensiveness notwithstanding, as a self-identified feminist, I’m pretty proud of the Ruby community.

I’ve become a regular Mercurial user in the past year, whereas I’ve only dabbled in Git, mostly when contributing to other projects. Most of the Ruby Web development world (i.e. Rails, etc.), on the other hand, has switched full-bore to Git. Advocates of git sing the virtues of the branch-implement-rebase workflow; its detractors proclaim rebase harmful.

Rather than waste bits talking Git down or making apologia for Mercurial, though, I’ll describe how I use Mercurial to achieve the same workflows that Git users seem to espouse. I think the Mercurial way is cleaner, but I’m also pretty sure that we’re all newbies in the DVCS game.

Update: There was some good discussion on the Mercurial mailing list about this.

        <span id="more-1135"></span>

        <h2>Small topic branches against a changing trunk/master/default</h2>

The seemingly most-quoted use of rebase is this: you create a “topic” branch, i.e. a short-lived branch to develop a particular feature, and start implementing. Meanwhile, the master branch (or trunk to Subversion users, default branch to Mercurial users) has some changes committed to it that you want to pull in.

Now, when you finally finish implementing your feature, you want to submit a clear, linear patch set upstream. (See git-rebase(1) for a fuller description.) In Subversion, you would just refrain from committing any changes until your implementation work was finished. In Git, you’d commit as you go, then rebase your repository against the current master, and then push your changes upstream.

The first thing to do when you have the urge to do this is to ask yourself, do I actually need to push a linear revision history? If you’re working on a branch to implement more than one feature, or doing a major subsystem rewrite, you should probably just fork off a named branch and let the revision graph make some cross-connects. On the other hand, if you’re working on a small, quick-to-implement patch that you’ll submit via e-mail, you probably do want this workflow.

In Mercurial, you would use the Mercurial Queues extension (mq, distributed with Mercurial ) to do this. What I do is as follows; for an alternate (probably better) strategy, see MqMerge on the Mercurial wiki.

# get working copy if we haven't already
$ hg clone http://example.com/upstream/repo

# initialize patch queue
$ hg qinit

# prepare to implement new feature.
# -m gives the commit message to be used.
$ hg qnew -m 'implement feature X' feature_x.patch

(edit/test/etc.)

# update the patch from our changes
$ hg qrefresh

# pop all patches and pull upstream changes
$ hg qpop -a
$ hg pull -u

# push our patches back on top of the updated tree
$ hg push -a

To me, this is a cleaner solution than rebasing. Using rebase, your local topic branch can’t be cloned by anyone else, or you’ll risk corrupting the version history. mq builds in this understanding. It won’t let you push changes upstream unless you either pop or finish (commit as real changesets) all your patches. Moreover, you can safely let others clone your repository by first popping all patches. They get your clean repository and none of your patches.

If you want to share your patches, you can use hg qinit -c to make the patch queue a repository in its own right. Then others can clone your repository, and then clone your patch queue, to help you test your patches.

Migrating a topic branch from one upstream branch to another

A second common use of git rebase is to migrate a set of changes on one branch to another. This is the example for rebase --onto used in git-rebase(1).

In Mercurial, you’d use the transplant extension (also distributed with Mercurial) to do this. Using the example from git-rebase(1), say you have this:

o---o---o---o---o  default
     \
      o---o---o---o---o  next
                       \
                        o---o---o  topic

and you want to move the changesets in the topic branch back onto default. I’d do this:

$ hg clone http://example.com/upstream/repo
$ hg update default
$ hg transplant --branch topic

If one of the changesets causes a conflict, transplant will bail out to let you fix the merge by hand. You can then continue the in-progress transplant:

$ hg transplant --continue    # or -c

Problems and other cases

There are some unresolved issues with the above. Using mq requires that you plan your next commit before you start implementing it; I find this to be extra mental overhead that’s not really necessary. It’s also not particularly obvious how to collaborate safely on shared patch queues. I think what you’d end up doing is having patches that alter the effects of previous patches, all stacked together. Since each patch is a commit, this is effectively the same as a normal revision history, but I don’t know if the patch-queue-as-repository setup works as I think it would in this case.

There also appears to be no --abort switch for the transplant command. One could be implemented easily, using the strip command from mq.

Finally, I’m sure there are more use cases for git rebase than the two I’ve mentioned here. I’m hoping to see some comments from you, dear readers, exploring edge cases and challenging new solutions.

Similar things for Mercurial have been written up, but they call hg repeatedly from bash functions. That means for each time your prompt is printed, the Python interpreter gets fired up three or four times. My implementation is written in Python using Mercurial’s API, so it only starts one external process.

Find it on bitbucket: http://bitbucket.org/krbullock/hg_ps1. Feel free to submit issues there, or write patches and submit pull requests.

Update 4 Oct 2009: Steve Losh went and one-upped me with a Mercurial extension, hg-prompt. It’s much more flexible than what I did with __hg_ps1, and last night I took the time to add MQ support to it. I’d recommend switching to it if you’re using __hg_ps1.