Skip to main content


Showing posts from September, 2012

Git Stash Blooper (Could not restore untracked files from stash)

The other day I accidentally did a git stash -a , which means it stashes *everything*, including ignored output files (target, build, classes, etc). Ooooops.. What I meant to do was git stash -u , meaning stash modifications plus untracked new files. Anyhows, I ended up with a big fat stash I couldn't get back out. Each time I tried, I got something like this: .../target/temp/dozer.jar already exists, no checkout .../target/temp/core.jar already exists, no checkout .../target/temp/joda-time.jar already exists, no checkout .../target/foo.war already exists, no checkout Could not restore untracked files from stash No matter how I tried checking out different revisions (like the one where I actually made the stash), or using --force, I got the same error. Now these were one of those "keep cool for a second, there's a git way to fix this"situation. I figured: A stash is basically a commit. If we look at my recent commits using   git log --graph --

Filtering out illegal characters using Guava

The other day, I needed to validate a text-field against a whitelist of characters. Actually, lots of text-fields needed lots of different sets of whitelists, but let's just stick to one for the sake of example. The text field "First name" is only allowed to contain any of these characters:   ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz°Žµ·žŒœŸÀÁÂÃÄÅÆ ÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝ Þßàáâãäåæçèéêëìíîï     ðñòóôõöøùúûüýþÿ .. and the user should be notified with which illegal characters she has entered in the field, if any. The knee-jerk reaction to this kind of logic is regular expressions, but my knee-jerk reaction to regexp is  to avoid it. The above character set probably doesn't fit with any of the predefined regexp notations, so it would probably be nasty anyway. Some  Guava fruits for coloring up this blog post ( image source ) So, let's put Google Guava to some use. It has some nifty utilities for working with sets   and other collections.

Stop using GitX - use GitX (L) instead

I noticed the other day that the Git homepage presents the original GitX as a GUI alternative on OS X.'s GUI clients However, development on GitX ceased three years ag o, and while there is an interesting fork from Brotherbard  (development has ceased there as well), the most active continuation takes place in the fork  GitX (L) . The wiki of the orginal GitX  confirms this . A fellow called Erik Blomqvist has put up which offers a more balanced view on the various forks. While there might be some value in the simplicity of the old GitX, three years is a long time in Git's development, and GitX is missing out on some newer Git features (like submodules). Anyhow, there are still a number of pages out there that says GitX is still the way to go. People are even still submitting stuff in the bug-tracker , which is awfully pointless, of course. Just keep this in mind next time someone asks you about a good Git GUI for Mac.