Sunday, September 09, 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 --all --decorate --oneline

...we see something like:


* dd7b26b (master) Extract method
* b0d0487 Rename one of the assertScreenForEvent methods
* ddbb532 Use strong typing for Events
| *-.   0374bd1 (refs/stash) WIP on master: d7fe9ab new class Event
| |\ \  
| | | * 2a958c1 untracked files on master: d7fe9ab new class Event
| | * 51510de index on master: d7fe9ab new class Event
| |/  
| * d7fe9ab (HEAD) new class Event
| * c59f0f3 Extract method
| * 74a987f Rename one of the assertScreenForEvent methods
| * 75e98b7 Use strong typing for Events
|/  
| * 40b5b29 (origin/master, origin/HEAD) added language-chooser


See my fatal stash up there? It's the 0374bd1. It looks a bit funky cause I was doing some rebasing at the same time (it has three parents which is actually one commit that was rewritten twice).

So following my line of thought: The stash is a commit gone bad. I need to reset it and then stash it again, without the -a flag.

So here we go. First check out the stash itself:

10093  git checkouto 0374bd1

And then, present it's a botched commit, and reset to previous commit, keeping the contents:

git reset HEAD~1

Goodie, got the stash back as local changes. Now, let's stash properly:

git stash -u

Voila. After this, the stash popped without problems.

I realize I could have probably unstashed the big failed stash if I had cleaned the repo first with git clean -dfx, but then I would've lost a lot of annoying things like IDEA config files, etc.

Hope this post will help out anyone googling the error message.

Friday, September 07, 2012

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.

If you consider the user's input characters as one set, and the above whitelist characters as a second set, you can find the characters that appear in the first set, but not in the second like this (see the whole class here):

[Loading gist....]

That's pretty much it. I've put a whole example project along with tests on Github.

Here are the tests showing off some usage:
[Loading gist....]

I will probably be adding some more Guava examples to that project over time.

Sunday, September 02, 2012

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.

git-scm.com's GUI clients
However, development on GitX ceased three years ago, 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 gitx.org 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.