technicalpickles / homesick

Your home directory is your castle. Don't leave your dotfiles behind.

homesick

Your home directory is your castle. Don't leave your dotfiles behind.

Homesick is sorta like rip, but for dotfiles. It uses git to clone a repository containing dotfiles, and saves them in ~/.homesick. It then allows you to symlink all the dotfiles into place with a single command.

We call a repository that is compatible with homesick to be a 'castle'. To act as a castle, a repository must be organized like so:

• Contains a 'home' directory
• 'home' contains any number of files and directories that begin with '.'

To get started, install homesick first:

gem install homesick

Next, you use the homesick command to clone a castle:

homesick clone git://github.com/technicalpickles/pickled-vim.git

Alternatively, if it's on github, there's a slightly shorter way:

homesick clone technicalpickles/pickled-vim

With the castle cloned, you can now link its contents into your home dir:

homesick link pickled-vim

You can remove symlinks anytime when you don't need them anymore

homesick unlink pickled-vim

If you need to add further configuration steps you can add these in a file called '.homesickrc' in the root of a castle. Once you've cloned a castle with a .homesickrc run the configuration with:

homesick rc CASTLE

The contents of the .homesickrc file must be valid Ruby code as the file will be executed with Ruby's eval construct. The .homesickrc is also passed the current homesick object during its execution and this is available within the .homesickrc file as the 'self' variable. As the rc operation can be destructive the command normally asks for confirmation before proceeding. You can bypass this by passing the '--force' option, for example homesick rc --force CASTLE.

If you're not sure what castles you have around, you can easily list them:

homesick list

To pull your castle (or all castles):

homesick pull --all|CASTLE

To commit your castle's changes:

homesick commit CASTLE

To push your castle:

homesick push CASTLE

To open a terminal in the root of a castle:

homesick cd CASTLE

To open your default editor in the root of a castle (the $EDITOR environment variable must be set):

homesick open CASTLE

To execute a shell command inside the root directory of a given castle:

homesick exec CASTLE COMMAND

To execute a shell command inside the root directory of every cloned castle:

homesick exec_all COMMAND

Not sure what else homesick has up its sleeve? There's always the built in help:

homesick help

If you ever want to see what version of homesick you have type:

homesick version|-v|--version

.homesick_subdir

homesick link basically makes symlink to only first depth in castle/home. If you want to link nested files/directories, please use .homesick_subdir.

For example, when you have castle like this:

castle/home
`-- .config
    `-- fooapp
        |-- config1
        |-- config2
        `-- config3

and have home like this:

$ tree -a
~
|-- .config
|   `-- barapp
|         |-- config1
|         |-- config2
|         `-- config3
`-- .emacs.d
    |-- elisp
    `-- inits

You may want to symlink only to castle/home/.config/fooapp instead of castle/home/.config because you already have ~/.config/barapp. In this case, you can use .homesick_subdir. Please write "directories you want to look up sub directories (instead of just first depth)" in this file.

castle/.homesick_subdir

.config

and run homesick link CASTLE. The result is:

~
|-- .config
|   |-- barapp
|   |     |-- config1
|   |     |-- config2
|   |     `-- config3
|   `-- fooapp        -> castle/home/.config/fooapp
`-- .emacs.d
    |-- elisp
    `-- inits

Or homesick track NESTED_FILE CASTLE adds a line automatically. For example:

homesick track .emacs.d/elisp castle

castle/.homesick_subdir

.config
.emacs.d

home directory

~
|-- .config
|   |-- barapp
|   |     |-- config1
|   |     |-- config2
|   |     `-- config3
|   `-- fooapp        -> castle/home/.config/fooapp
`-- .emacs.d
    |-- elisp         -> castle/home/.emacs.d/elisp
    `-- inits

and castle

castle/home
|-- .config
|   `-- fooapp
|       |-- config1
|       |-- config2
|      `-- config3
`-- .emacs.d
    `-- elisp

Supported Ruby Versions

Homesick is tested on the following Ruby versions:

• 2.2.6
• 2.3.3
• 2.4.0

Note on Patches/Pull Requests

• Fork the project.
• Make your feature addition or bug fix.
• Add tests for it. This is important so I don't break it in a future version unintentionally.
• Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
• Send me a pull request. Bonus points for topic branches.

Need homesick without the ruby dependency?

Check out homeshick.

Copyright

Copyright (c) 2010 Joshua Nichols. See LICENSE for details.

homesick's Issues

Have recursive modules initialized or install hooks

It would be nice when importing, that git submodules where recursively initialized. Something like this:
git submodule foreach --recursive "git submodule init; git submodule update"

Another good thing would be if we could have some "hook", after download or updating. What do you think of this? I could create a patch for this one.

Docs don't cover "generate"

The existing docs seem to assume that you already have a castle.

Is there a doc somewhere covering the use of generate to get started with a new castle?

Version command

There doesn't seem to be a way to check homesick's version from the command line using homesick itself. gem list homesick is helpful, but it would still be nice if this were built into homesick with commands like these:

• homesick version
• homesick -v
• homesick --version

Test failures on OSX Mavericks

I just cloned the repo onto a new computer running OSX Mavericks and I'm getting test failures. This seems pretty weird as AFAIK all of the tests are passing in Travis. I haven't dug into this too much yet but thought I'd post here in case anyone has a 'quick fix'. Screenshot below.

Improve test coverage

See https://coveralls.io/r/technicalpickles/homesick

Use file/git libraries instead of always shelling out

Advantages

• Shelling out takes a while, and you can get major performance and stability boosts with the right libraries.
• We could save time writing ruby wrappers around command line functionality by using an existing library.
• The code would be a bit less bloated with generalized file/git/etc. code placed somewhere else.
• Many Ruby libraries give comfortable object-oriented interfaces to existing command line functionality.

File stuff

Ruby has a lot of awesome command-line-inspired libraries built in, including FileUtils, which could easily replace many calls to commands like mv, cp, rm, and ln.

Git stuff

Grit looks pretty awesome, as it's what GitHub uses internally. See Supercharged Ruby-Git.
Grit is deprecated, and its readme recommends switching to Rugged.

New collaborators, welcome!

Regretfully, I haven't been using this tool for my day to day work for awhile, so it's been a bit under maintained for awhile. Sorry about that 😞

I had been thinking about this problem at lot recently, having projects that I'm not actively working on or interested in working on, and came across The Pull Request Hack, and this seems basically like a briallant idea. Therefore, we try it here 😄

I think I've added everyone who has ever sent a pull request. There is still the matter of the gem pushing, so if you can let me know rubygems logins or email accounts, I can add there. Or, ping me on a new issue, but with question mark time expectation on pushing it.

Lastly, I won't say too much on how to work with other collaborators, but I would still suggest feature branches and pull requests for discussion, rather than just going off master. That's just my 0.05 💵 though.

homesick symlinks use absoulte paths

Hi there,

I like homesick!

However, I noticed that it uses absolute paths in the symlinks it creates. Is there a reason for this? I noticed this when I mounted the home directory in a rescue system under another path and all symlinks where broken. I think relative symlinks would work fine in this situation and see no other disadvantages. So my question is: why does homesick use absolute paths and could/should it be changed to relative paths?

Best Regards
MIchael

Consider using a Gitter chat room for development

Gitter is a web chat room service for GitHub projects, which is free for open source repositories. I have created a chat room at https://gitter.im/technicalpickles/homesick to try out Gitter, and I'm curious about what you would think.

While I'm not against using GitHub issues for conversations, I feel like there have been a few longer conversations that were important but often got off topic from issues, and I feel these sorts of conversations may work better in a chat room than in GitHub issue comments.

I added any homesick committers that I could find that are already on Gitter, but feel free to join Gitter to check out the room if you haven't yet (you just have to log in with your GitHub account).

Thor dependency not included in gemspec

Looking at the Gemfile, the thor dependency is specified, but the gemspec is not getting the dependency. Possibly something up with jeweler?

If git is not installed, clone will fail quietly

This tripped me up today as I set up a new system. If you use the clone command and git is not installed, homesick displays a message saying that is was cloned but actually does nothing. This is a edge case, as I'm sure most of us have git installed but it could trip up a newb.

homesick clone failure isn't handled properly

I've noticed that "homesick clone GITPATH" often fails silently, outputting the exact message as when it succeeds. The following occurs on a system with no git installed:

alex@precise64:~$ homesick clone git://github.com/technicalpickles/dotpickles.git
   git clone  git://github.com/technicalpickles/dotpickles.git to /home/alex/.homesick/repos/dotpickles

The same behavior occurs if the repository doesn't exist, etc.

It seems to me that the right behavior would be to store the return value of the system call, and raise an exception if appropriate. See https://github.com/technicalpickles/homesick/blob/master/lib/homesick/actions.rb#L16

Should we drop our runtime dependency on git?

Libraries like Rugged open the possibility of using git features implemented in Ruby instead of shelling out to git. But should homesick still depend on having git installed at runtime? The alternative would be to keep depending on git and to show warning/error messages when a command fails because git could not be found.

Related issues

• #25
• #61
• #74 (especially related)
• #85
• #91
• #97 (with the new exec command, users could use commands like homesick exec git push instead of homesick push)

CC @technicalpickles @christianbundy @JCook21

Not every repo should clone to `dotfiles`

When cloning a GitHub repo, homesick should be smart enough not to clone every repo named "dotfiles" into the same place.

My suggestion would be to clone the repositories and into the user's name and repo name, so that christianbundy/dotfiles would clone to christianbundy-dotfiles, etc.

The way that we're currently using it, it's incredibly difficult to have multiple castles, since many dotfiles are simply named "dotfiles".

Let me know your thoughts on this, thanks!

Consider setting up Coveralls

Coveralls works with your continuous integration server to give you test coverage history and statistics.

https://coveralls.io

See a previous discussion in #96.

symlink won't overwrite .oh-my-zsh

Hi, I'm trying to sync my oh-my-zsh across 2 machines and found out about homesick. It worked for .zshrc, but not the .oh-my-zsh folder. The repo I'm pulling from has an updated rvm plugin in .oh-my-zsh/plugins/rvm, but when I try to symlink, it asks me if I want to overwrite .oh-my-zsh, and when I say "Y", it still doesn't update the plugins/rvm folder and also doesn't create the symlink.

What am I doing wrong? Is homesick not able to overwrite folders + all subdirectories?

Gemfile is missing source

To be able to use Gemfile with bundler it needs a source. I've added a source :gemcutter in my bundler-src branch at http://github.com/jacobat/homesick/tree/bundler-src

Cloning the same thing twice with curious results

I accidentally typed "homesick clone whatever" twice, when I actually meant "symlink" the second time round. This is what happened:

$ homesick clone ilkka/oh-my-zsh
     git clone  git://github.com/ilkka/oh-my-zsh.git to /home/ilkkala/.homesick/repos/ilkka/oh-my-zsh
$ homesick clone ilkka/oh-my-zsh
     symlink  /home/ilkkala/.homesick/repos/ilkka/oh-my-zsh to /home/ilkkala/.homesick/repos/oh-my-zsh

So, is that by design?

Creating consistent commands

It's trivial, but personally, I've found myself typing homesick link abc/xyz – and after thinking about it, it seems like we have an issue with consistency between commands.

I think that we should decided on whether the command should be symlink or link (I prefer the latter for brevity), and format both commands to adhere to that. Either:

homesick link abc/xyz
homesick unlink abc/xyz

or

homesick symlink abc/xyz
homesick unsymlink abc/xyz

But mixing and matching commands is confusing, and I don't think that it's the best way to go.

The shortcut `homesick technicalpickles/pickled-vim` clone and symlink automatically

I think it would be great to have a shortcut feature, allowing you to quickly and easily grab your castle and get to work, rather than trying to remember how to homes[h]ick. cc: @andsens

Add more options to the exec command

--all

In order to keep certain functionality if we remove git as a runtime dependency, we should add a homesick exec --all flag to make it easier to run commands on every cloned castle.

As an example, here's what the --all flag for homesick pull looks like currently:

method_option :all,
              type: :boolean,
              default: false,
              required: false,
              desc: 'Update all cloned castles'

--pretend and --quiet

This will be especially useful for #99.

Handling of ssh aliases

I have a setup where I have a gitolite server running. To access it I'm using an ssh alias like: gitolite:homesick. Currently homesick doesn't know how to handle a path like that.

I've patched the cloning code to handle the case where such a "URI" is passed. It's in my ssh-alias branch, which is based of my malformed-uri-fix branch, at: http://github.com/jacobat/homesick/tree/ssh-alias

Bad handling of malformed uri's

When trying to clone a uri that doesn't live up to the expectations of homesick it throws a non descriptive error: "undefined method `join' for nil:NilClass" because the destination variable contains nil. Also it actually does the clone so a repository will be initialized.

I've changed this behaviour to raise an exception with the message: "Unknown URI format: #{uri}" and not initializing a new repos.

The code is in my malformed-uri-fix branch: http://github.com/jacobat/homesick/tree/malformed-uri-fix

cloning with github shortcut leads to compound name

Cloning a castle using the github shortened syntax ends up placing the files in a [user] subdirectory, which is less than useful:

vagrant@vagrant-ubuntu-raring-64:~$ homesick clone billwanjohi/dotfiles
   git clone  https://github.com/billwanjohi/dotfiles.git to /home/vagrant/.homesick/repos/billwanjohi/dotfiles

Compared to:

vagrant@vagrant-ubuntu-raring-64:~$ homesick clone https://github.com/billwanjohi/dotfiles.git
   git clone  https://github.com/billwanjohi/dotfiles.git to /home/vagrant/.homesick/repos/dotfiles

Update repo description to remove gendered terms

Please match it to the changes in #64

'homesick list' does not properly list castles cloned via 'homesick clone ghuser/repo'

 $ homesick clone git://github.com/tobias/dotfiles.git
   git clone  git://github.com/tobias/dotfiles.git to /Users/tobias/.homesick/repos/dotfiles

 $ homesick clone tobias/dotfiles
   git clone  git://github.com/tobias/dotfiles.git to /Users/tobias/.homesick/repos/tobias/dotfiles

 $ homesick list
    dotfiles  git://github.com/tobias/dotfiles.git
    tobias  

Not only is list broken in this case, but so is duplicate castle detection.

From looking at the specs, it looks like namespacing the repos as user/repo is as designed, but is that necessary? Do you see folks using homesick with other peoples dotfiles?

If you want to keep namespacing, I think the fixes needed here are to have list detect and properly show the namespaced repos, and for clone to detect a full github git url, and namespace it as well to catch the duplicated castle. I'd see the list output as:

$ homesick list
    dotfiles  git://some-other-git-host.com/dotfiles.git
    tobias/repo_x  git://github.com/tobias/repo_x.git

If that sounds good to you, I'd be glad to implement these fixes.

Tobias

Clone SSH URLs by default

If you do this:

homesick clone nslater/dotfiles

Homesick clones using the HTTPS URL, meaning that if you homesick cd dotfiles, make some changes, and then try to push, you will be prompted for your password. (Assuming you as using SSH keys for authentication with GitHub.)

If you do this:

homesick clone git://github.com/nslater/dotfiles.git

And try the same, you actually get this:

fatal: remote error: 
  You can't push to git://github.com/nslater/dotfiles.git
  Use https://github.com/nslater/dotfiles.git

What I actually needed to do was:

homesick clone [email protected]:nslater/dotfiles.git

That works perfectly when you make changes from within your homesick dir.

I think this is important because I make all of my changes inside the homesick dir, because it saves a push, fetch, and rebase cycle between my main checkout, and the homesick clone. But it's frustrating that the default two documented methods produce a local clone that either prompts me for my password, or doesn't let me push.

merging of files in populated subfolders

I am not really sure if this is a bug, a feature request or I am just using homesick the wrong way but here it goes:

I am using zsh with oh-my-zsh and I modified one of the themefiles in .oh-my-zsh/themes which I would like to be handled by homesick.

If I recreate the folder structure in the homesick home folder (~/dotfiles/.oh-my-zsh/themes/foo.theme), add the file to homesick and upload it to github, when cloning the castle it doesn't just merge the themefile into the folder (a symlink would be perfect) but instead replaces the whole .oh-my-zsh folder, effectively destroying the ohmyzsh installation.

Use wrappers around action methods to handle quiet/pretend invocation of commands

Here's an example of running grep say_status lib/homesick/actions.rb on homesick's source.

say_status 'git clone', "#{repo} to #{destination.expand_path}", :green unless options[:quiet]
say_status :exist, destination.expand_path, :blue unless options[:quiet]
say_status 'git init', '' unless options[:quiet]
say_status 'git init', 'already initialized', :blue unless options[:quiet]
say_status 'git remote', "add #{name} #{url}" unless options[:quiet]
# about 20 lines removed for brevity

The quiet and pretend options are often checked manually, which leads to fairly complex looking code.

Instead, I think it would be cleaner to use methods that handle quiet/pretend invocation for us. I vaguely remember seeing something in Thor's source code about a quiet? getter method that is used in say_status, but I couldn't figure out how to set this yet. It would be nice to use features built into Thor if there are any for this, but worst case we can add our own wrapper methods.

Environment is borked after running `homesick cd`

Steps to reproduce:

Put this in your ~/.bash_profile file:

if [ -f $(brew --prefix)/etc/bash_completion ]; then
    . $(brew --prefix)/etc/bash_completion
    GIT_PS1_SHOWDIRTYSTATE=true
    PS1='\u@\h \w$(__git_ps1 " (%s)") \[\e[m\]$ '
    export PS1
fi

Now run:

homesick cd YOUR_REPO

You will get the following error:

bash: __git_ps1: command not found

This appears every time you enter a new command in the new shell.

Do you need another maintainer?

I see the last commit was almost a year ago, and there's a bunch of outstanding pull requests. I'm using homesick rather extensively; if you don't have the time to maintain it anymore, I'd be happy to help out.

`homesick list` doesn't work with ruby 2.0.0-p0

Looks that there is a problem with Pathname.glob in this line:

dirs = Pathname.glob("#{repos_dir}/**/*/.git")

It just returns empty array

Tested on OSX 10.8.3 and Ubuntu 12.04

Symlink home dir and .homesick_subdir

Hey there, I have an issue in my configuration with my home directory.

My home resides in /home/user but in fact the /home is a symlink to /usr/home.

The issue that I'm facing is that this breaks .homesick_subdir altogether. The contents of the subdir file are actually getting symlinked instead of merged and the symlink command tries to link the castle files to themselves:
/usr/home/user/.homesick/repos/zsh-conf/home/.zsh.d/aliases.d -> /usr/home/user/.homesick/repos/zsh-conf/home/.zsh.d/aliases.d.

I can work around this issue by overriding my HOME environment variable:

HOME=/usr/home/user homesick symlink zsh-conf

Enable merging of directories

If, for example, I put .config/MyApp in a castle, homesick symlink should have an option to merge with an existing .config folder in my home directory (ie ./config/MyApp is symlinked rather than .config).

Castle not found but listed with 'homesick list' ?

What could be going wrong here?

nico@chocomousse:~ $ homesick list
   dotfiles  git+ssh://git.ngaloppo.org/home/ngaloppo/git.ngaloppo.org/dotfiles.git
nico@chocomousse:~ $ homesick link dotfiles
   error  Castle dotfiles did not exist in /Users/nico/.homesick/repos

.homesickrc won't eval

First time playing around with homesick, and was thinking of creating an improved fork of this project: https://github.com/factorylabs/vimfiles that doesn't require manually running the install.sh after the homesick clone. Ran into this bug trying to use a .homesickrc file:

lib/homesick.rb:58:in `eval': can't convert Pathname into String

Adding to_s after the expand_path call seems to fix it.

e

Add branch name to homesick push

As a safety check, I have push.default set to nothing in my gitconfig. When I try to use homesick push, I get

$ homesick push
    git push  
fatal: You didn't specify any refspecs to push, and push.default is "nothing".

Could 'master' or something else be added as the pushed branch?

diff functionality appears to be broken for directories

➜  homesick symlink dotfiles-osx
    conflict  /Users/agh/bin exists
Overwrite /Users/agh/bin? (enter "h" for help) [Ynaqdh] h
        Y - yes, overwrite
        n - no, do not overwrite
        a - all, overwrite this and all others
        q - quit, abort
        d - diff, show the differences between the old and the new
        h - help, show this help
Overwrite /Users/agh/bin? (enter "h" for help) [Ynaqdh] d
diff: /Users/agh/bin/bin20140322-77340-ixkd7r: No such file or directory
Retrying...
Overwrite /Users/agh/bin? (enter "h" for help) [Ynaqdh]

Is this project actively maintained?

I see that you accept some pull requests, but there are issues that have been sitting around for over three months (a la #50) without any reply. I'd like to start getting involved in this project, but I wanted to make sure that there's somebody on the other end of the screen who's open to discussing new features, fixing bugs, etc.

Let me know your thoughts, thanks!

Release 1.0.0

Filing this for tracking:

• #71 for moving to > ruby 1.8
• #79 for more testing
• bump version & release

cc @JCook21 @thenickperson

Add usage information for the .homesickrc

I could not seem to find any information on the .homesickrc within the readme, and the documentation for the homesick rc command only mentions that it will run your .homesickrc file. I feel that it would be helpful to fully document this feature (at least in the readme), especially since I did not realize that this feature existed until I saw it in the changelog, issues, and source code.

Additionally, it would help to mention that the file should contain ruby code (as supposed to bash or yaml), as I also found that confusing.

Related commit: 8dbd5a9

General refactoring

I have started work on some of this on my refactor branch several of my branches. If you would like to work on the branch with me, let me know and I can accept PRs / add you as a collaborator.

Ideas

• Make rubocop happy with our source code.
• Separate implementation and specs into more files.
• Reduce duplication.
• Make things more modular
• Use more libraries to avoid "reinventing the wheel".
• Move each group of commands into their own/class file. For example, symlink/unsymlink could be together. We could also have spec files separated into these command groups.

Thanks to @trobrock for some of these refactoring ideas.

Related issues

• #62
• #74
• #75

printing bug in the "generate" command

There seems to be a bug when listing the results of the "generate" command:

[^_^][240][~]$  ~/.gem/ruby/1.9.1/bin/homesick generate /tmp/toto
    create  mp/toto
  git init  
    create  mp/toto/home

It should be "/tmp" instead of "mp".

P.S.: Thanks for this great piece of software. This Looks exactly like what I was looking for. :)
Only thing that might be missing is linking of the bin directory for shellscripts.

I used dropbox for syncing dotfiles until now, but it's hard to set it up correctly on servers + it doesnt' allow separating dotfiles from other private documents.
I'll probably be using a private git repo at http://www.assembla.com/ first (until my config files and shellscripts are ready for public consumption ^^ ).

Refresh command to do update checks

Thought I'd give a little inspiration for a (IMO) very useful command I implemented in the bash version: refresh
It checks if a castle has been pulled the last N days and prompts the user to pull if they have not. This goes very well with a .bashrc or .zshrc file.
description
implementation

Wrap all git commands automatically

Homesick currently provides a command for every git command that can be executed through it manually. While this offers a convenient interface for some git commands, it means that we would have to add more homesick commands every time we wanted to use a git command that isn't provided. Instead, we could take the approach that tools like hub use and automatically provide all of git's interface by wrapping all of it with dynamic system calls. Homesick could intercept some git commands before shelling out to provide syntax sugar, and support the rest by only shelling out for compatibility.

Example

Advantages:

• Makes git-related homesick commands a lot easier to manage, since it would make homesick more modular.
• Adapts to changes in git's interface more easily.
• If we offer all git functionality, it would be less confusing for new users to figure out how to use git commands through homesick.
• In the end, this will probably make the code a bit lighter and more manageable, since we are currently wrapping a lot of git commands manually.

Disadvantages:

• Because homesick is not strictly a git wrapper, some homesick commands may conflict with git commands (especially the help command). We could always fix this by adding a prefix command like homesick git, though.
• We might need to do special things in terms of dynamically wrapping commands, especially for situations like clone where we would have to intercept where the repository is placed. Maybe we could still offer our own wrappers for commands like this, separate from out git interface.
• This would most likely lead to breaking changes.
• This would require us to shell out any automatically-provided git functionality to git itself, and would prevent us from using a git library for this part of homesick. However, we could always use a library elsewhere, and in my opinion switching to a git library is looking like it will be too difficult to be worth it anyway (see #74).

Issue labels

I've noticed that homesick's GitHub repo doesn't have any issue labels. Is this intentional, or should we add some of the default GitHub issue labels? If we want labels, I would be happy to start adding them.

homesick unlink CASTLE

I havnt found if there is an unlink command in homesick, thats a feature I would love to see!

homesick cloning of assembla repository gives some error messages, but seems to work

Here are the error messages:
[^_^][363][~]$ /home/kiaaze/.gem/ruby/1.9.1/bin/homesick clone [email protected]:bin_and_dotfiles.git
git clone [email protected]:bin_and_dotfiles.git to /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles
/home/kiaaze/.gem/ruby/1.9.1/gems/homesick-0.5.1/lib/homesick.rb:38:in block in clone': undefined methodjoin' for nil:NilClass (NoMethodError)
from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor/actions.rb:167:in block in inside' from /usr/lib/ruby/1.9.1/fileutils.rb:121:inchdir'
from /usr/lib/ruby/1.9.1/fileutils.rb:121:in cd' from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor/actions.rb:167:ininside'
from /home/kiaaze/.gem/ruby/1.9.1/gems/homesick-0.5.1/lib/homesick.rb:21:in clone' from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor/task.rb:22:inrun'
from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor/invocation.rb:109:in block in invoke' from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor/invocation.rb:116:incall'
from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor/invocation.rb:116:in invoke' from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor.rb:161:inblock in start'
from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor/base.rb:379:in start' from /home/kiaaze/.gem/ruby/1.9.1/gems/thor-0.13.8/lib/thor.rb:140:instart'
from /home/kiaaze/.gem/ruby/1.9.1/gems/homesick-0.5.1/bin/homesick:9:in <top (required)>' from /home/kiaaze/.gem/ruby/1.9.1/bin/homesick:19:inload'
from /home/kiaaze/.gem/ruby/1.9.1/bin/homesick:19:in `

'

But despite those errors, it seems to work fine:

[^_^][428][~]$  ls ~/.homesick/repos
[email protected]:bin_and_dotfiles  gugu  pickled-vim
[^_^][429][~]$  ls ~/.homesick/repos/[email protected]\:bin_and_dotfiles/
bins  home
[^_^][430][~]$  ls -A ~/.homesick/repos/[email protected]\:bin_and_dotfiles/home/
.bash_aliases  .bash_env~       .bash_history  .bash_profile   .bash_prompt  .bashrc~                 .hello  old
.bash_env      .bash_functions  .bash_logout   .bash_profile~  .bashrc       .bashrc.20100119_122209  laptop  swordfish
[^_^][431][~]$  

[^_^][433][~]$  ls ~/.bashrc
ls: cannot access /home/kiaaze/.bashrc: No such file or directory
[0_0->ret=2][434][~]$  homesick symlink [email protected]:bin_and_dotfiles
homesick: command not found
[0_0->ret=127][435][~]$  /home/kiaaze/.gem/ruby/1.9.1/bin/homesick symlink [email protected]:bin_and_dotfiles
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_logout to /home/kiaaze/.bash_logout
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bashrc to /home/kiaaze/.bashrc
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_env to /home/kiaaze/.bash_env
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_prompt to /home/kiaaze/.bash_prompt
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_profile~ to /home/kiaaze/.bash_profile~
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_functions to /home/kiaaze/.bash_functions
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.hello to /home/kiaaze/.hello
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_env~ to /home/kiaaze/.bash_env~
    conflict  .bash_history exists
Overwrite .bash_history? (enter "h" for help) [Ynaqdh] n
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bashrc~ to /home/kiaaze/.bashrc~
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_profile to /home/kiaaze/.bash_profile
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bashrc.20100119_122209 to /home/kiaaze/.bashrc.20100119_122209
    symlink  /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_aliases to /home/kiaaze/.bash_aliases
[^_^][436][~]$  ls ~/.bashrc
/home/kiaaze/.bashrc
[^_^][437][~]$  ls -l /home/kiaaze/.bash*
lrwxrwxrwx 1 kiaaze kiaaze    83 2010-07-21 09:33 /home/kiaaze/.bash_aliases -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_aliases
lrwxrwxrwx 1 kiaaze kiaaze    79 2010-07-21 09:33 /home/kiaaze/.bash_env -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_env
lrwxrwxrwx 1 kiaaze kiaaze    80 2010-07-21 09:33 /home/kiaaze/.bash_env~ -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_env~
lrwxrwxrwx 1 kiaaze kiaaze    85 2010-07-21 09:33 /home/kiaaze/.bash_functions -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_functions
-rw------- 1 kiaaze kiaaze 10631 2010-07-21 05:23 /home/kiaaze/.bash_history
lrwxrwxrwx 1 kiaaze kiaaze    82 2010-07-21 09:33 /home/kiaaze/.bash_logout -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_logout
lrwxrwxrwx 1 kiaaze kiaaze    83 2010-07-21 09:33 /home/kiaaze/.bash_profile -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_profile
lrwxrwxrwx 1 kiaaze kiaaze    84 2010-07-21 09:33 /home/kiaaze/.bash_profile~ -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_profile~
lrwxrwxrwx 1 kiaaze kiaaze    82 2010-07-21 09:33 /home/kiaaze/.bash_prompt -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bash_prompt
lrwxrwxrwx 1 kiaaze kiaaze    77 2010-07-21 09:33 /home/kiaaze/.bashrc -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bashrc
lrwxrwxrwx 1 kiaaze kiaaze    78 2010-07-21 09:33 /home/kiaaze/.bashrc~ -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bashrc~
lrwxrwxrwx 1 kiaaze kiaaze    93 2010-07-21 09:33 /home/kiaaze/.bashrc.20100119_122209 -> /home/kiaaze/.homesick/repos/[email protected]:bin_and_dotfiles/home/.bashrc.20100119_122209
[^_^][438][~]$  

(yes, I need to do some more cleanup. ^^ )

Add --pretend and --quiet support for the exec command

This will be especially useful for #99.