Comments for jamis's capistrano  

You’re right, my bad. I grabbed the wrong name/email when I made the commit. My apologies to both of you! Looks like I even pasted the wrong name in the changelog. :( This is what happens when I try to catch up on patches too late at night!

I think the original author of this patch isn’t me but Matthias Marschall, since I have no recollection of having fixed this :)

I actually found this method useful and put into my recipes a check to see if it was necessary to add default_run_options[:pty] = true; if the version was higher than 2.1.0.

Unsure if this is related, but I had a problem after updating to the latest version that seems similar. I resolved it by specifying a branch, assuming that it no longer assumed “master” if no branch was named.

that is, 
"git ls-remote URL HEAD" 
works but
"git ls-remove -h -t URL HEAD" 
does not

This change is breaking my deploy. Don’t know exactly why. Behold:

$ git —version git version 1.6.0.4

$ git ls-remote cbgit:project.git HEAD →e92ba56411edebf4a9a92ae17caa6b43a0fb4576 HEAD

$ git ls-remote -h -t cbgit:openfriends-provider.git HEAD →nothing!!!

Where can I find the why/how of this change? Thanks!

That’d be great! Thanks.

I have an initial replacement working and will submit a pull request later this week.

I’ve been wanting to implement this for a long time, so I’m glad to see that someone has done it!

But this is much different from how the same option works in Rake. For consistency, it should match any part of the name of any task, not just the full namespace.

Or is there a reason that this was implemented differently from how Rake works?

It would be really cool to have this branch merged into the master, cause since 2.3 I can’t use Capistrano with some of my old installations (net-ssh version is too high and breaks 1.3.1 compatibility).

Thank you for this commit – I just ran into an issue with the —tags parameter – it made git not download the branches.

Do you think this might be a bug in git? The git documentation doesn’t state anything about —tags NOT downloading heads, as well.

I’m going to do a post on the git mailing list.

:)

This changeset appears introduced issues for me.

The argument ‘revision’ is being passed in with a value of “origin/switchboard_base” (the name of the branch I’m deploying), which results in the execution of the command:

git ls-remote git@market:/var/gitrepo/market origin/switchboard_base

This command returns absolutely nothing. If I change the command to:

git ls-remote git@market:/var/gitrepo/market switchboard_base

It does do something. Very likely an issue with this command, which used to work in 2.2.x:

set :branch, “origin/switchboard_base”

So, based on this, I guess I should no longer be passing in remote branch names.

I’ll fork and add a change that will warn if the remote revision is unresolvable. Overall, this is an exciting change – We’ve had issues before with deploying without first fetching.

Thanks, Tim