I'm largely curious if I am to be considered a Merry Man. In particular, one of Jamis's Merry Men. Anyhow, this is like the one open ticket on Git that we have right now and since I don't use local repos to deploy from, and I haven't received a patch from anybody that it does affect, I haven't dug into it yet. If I have time this weekend, since it has come up quite a bit now, I'll try to find some time to sit down and recreate this and see if I can't fix it without breaking something else. :)
If anyone has a suggestion that works for them that I could test, that would be helpful, otherwise I'll give recreating it a shot. The easiest meantime workaround would be to put the git repo on an intermediate server that they both have ssh access to, even if it's the local or deployed server - just access it via ssh instead of file://. Thanks, Scott On Thu, Jun 19, 2008 at 2:14 PM, walt_d <[EMAIL PROTECTED]> wrote: > > Well, looks like we're quite a bunch here - all tumbling around in the > dark, fighting the same piece of code :) > > We could all hold hands and pray that Jamis & his Merry Men Will > Return <:) > > > > On 17 Jun, 11:59, Michiel de Mare <[EMAIL PROTECTED]> wrote: >> I have the same problem, so I reverted back to 2.2. The error message >> is supremely unhelpful, and doesn't even show whichgitcommand is >> being executed. cap -d doesn't work either. >> >> On Jun 13, 7:52 pm, "Erik Kastner" <[EMAIL PROTECTED]> wrote: >> >> > I believe that this commit caused this >> > behavior:http://github.com/jamis/capistrano/commit/ec9a7fa52c9f417a9a01a7e764b... >> >> > I'm trying to think of a workaround, but it comes down to a different >> > philosophy about where the knowledge of the repository should live. >> > It's either >> > old way: machine issuing cap command knows >> > new way: machines doing the code check out know >> >> > On Fri, Jun 13, 2008 at 1:44 PM, H. Wade Minter <[EMAIL PROTECTED]> wrote: >> >> > > I'm deploying a Rails app to the same server that houses thegit >> > > repository. I'm trying to use this in my deploy.rb: >> >> > > set :scm, :git >> > > set :repository, "file:///usr/local/git/carpool.git" >> > > set :deploy_via, :remote_cache >> > > set :branch, "master" >> > > set :repository_cache, "git_cache" >> > > set :use_sudo, false >> >> > > In Capistrano 2.2, this works fine. However, in 2.3 and the just- >> > > released 2.4, I get: >> >> > > * executing `deploy:update_code' >> > > updating the cached checkout on all servers >> > > fatal: '/usr/local/git/carpool.git': unable to chdir ornotagit >> > >archive >> > > fatal: The remote end hung up unexpectedly >> > > *** [deploy:update_code] rolling back >> > > * executing "rm -rf /usr/local/www/carpool/releases/20080613174107; >> > > true" >> > > servers: ["10.5.88.49"] >> > > [10.5.88.49] executing command >> > > command finished >> > > /Library/Ruby/Gems/1.8/gems/capistrano-2.4.0/lib/capistrano/recipes/ >> > > deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision >> > > for 'master' on repository 'file:///usr/local/git/carpool.git'. >> > > (RuntimeError) >> > > from /Library/Ruby/Gems/1.8/gems/capistrano-2.4.0/lib/capistrano/ >> > > recipes/deploy/scm/base.rb:35:in `send' >> >> > > Is there a workaround or anything for this? Or are file:// repository >> > > URLs no longer supported? > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
