Capistrano deployment problem with git and windows

I had a problem deploying with Capistrano from a git repository (both local and remote depositories equally didn’t work) while on a Windows machine. The git version was probably 1.5 and Capistrano versions used were 2.4.* and 2.5.*

My capistrano settings were the following (besides the usual stuff):

set :deploy_via, :copy
set :copy_dir, "C:/caches/myapp"

I was running:

C:\myapp>cap deploy
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
executing locally: "git ls-remote ssh://git@myhost.com:myport/~/myapp HEAD"
* getting (via checkout) revision b6f590f2d59b3f6ae14e1f5278512f7f1b4edd1a to
C:/caches/myhost.com/20100312233007
executing locally: git clone -q ssh://git@myhost.com:myport/~/myapp C:\caches\myhost.com\20100312233007 && cd /D C:\caches\myapp.com\20100312233007 && git checkout -q -b deploy b6f590f2d59b3f6ae14e1f5278512f7f1b4edd1a
warning: Remote branch deploy not found in upstream origin, using HEAD instead
* processing exclusions...
*** [deploy:update_code] rolling back

....

(and a whole bunch of errors)

The command “git clone” failed to clone the code from the repository to the copy folder but copied it to my current folder from which I ran the command instead. After I switched to the latest version of git (1.7), it started to crash with a “Too many arguments” error. When I ran the command manually from the command line, everything was fine.

It seems that in the context of Ruby the “git clone” command is greedy, perceiving the commands chained with && as it’s destination folder, and it fails because this “destination folder” doesn’t look valid.

I had to put a hack to Capistrano to make “git clone” execute separately.

In \lib\ruby\gems\1.8\gems\capistrano-2.5.18\lib\capistrano\recipes\deploy\strategy\base.rb after the line 53 (cmd = cmd.split…)
add the following lines:

if cmd =~ /\s\&\&\s/ && cmd =~ /^git\s+clone/
cmd1, cmd = cmd.split(" && ", 2)
super(cmd1)
end

I don’t know if it would work for all possible scenarios, but it fixed my case. After that the application deployed just fine.