Git :remote_cache and remote branches

[Adam Salter]

Hi,
Saw a post not that long ago about a SVN problem with remote_cache...
Now it's Git's turn ;)

So I'm trying to do a :remote_cache and I have several branches in my
remote repo (on GitHub)... i deploy to different directories for my
branches... (I have a staging branch which gets merged back to master
when everything is considered 'complete')

So the way i specified this is using the multistage cap plugin and
having a cap file like:

set :application, "app_name"
set :repository, "g...@github.com:adamsalter/app_name.git -o staging"
set :scm, :git
set :branch, "staging"

Unfortunately this doesn't seem to work for cap... Cap seems to assume
there are no remote branches (ie everything comes from master).

Please correct me if I'm doing this wrong,
-Adam

[Jamis Buck]

I'm still new enough to git that I'm not sure I can troubleshoot this
one with you. Anyone more experienced want to help Adam out? I'll
watch this one from the sidelines, and take notes.

- Jaims

[Mislav Marohnić]

Hey Adam,

On Sat, May 3, 2008 at 4:23 PM, Adam Salter <adam.q...@gmail.com> wrote:

set :repository, "g...@github.com:adamsalter/app_name.git -o staging"

First of all, this line is wrong. It should go like this:

  set :repository, "g...@github.com:adamsalter/app_name.git"
  set :remote, "staging"

But after that, it still won't work. This is because the ":branch" options is not used for anything. It always defaults to master.

The option *is* used inside a method named "head", but that method is never called. This is a Capistrano bug for sure.

[Adam Salter]

I've actually investigated this myself...

I don't think:

set :remote, "staging"

does what we think it does (neither did '-o staging' for that matter), it basically just renames the remote reference on the deploy server from 'origin' to whatever you choose. Which doesn't change any functionality at all as far as I can see. The remote reference may as well be called 'origin'. (ie then remote branches become origin/staging, origin/better_branch etc.)

The problem is partly that git is a full DVCS. The github version of the repo, and the local, and the deploy server could all have totally different repos. I think the assumption should be that the github version and the deploy server ones are the same. The local one could differ.

-Adam

[Mislav Marohnić]

On Mon, May 5, 2008 at 2:34 AM, Adam Salter <adam.q...@gmail.com> wrote:

I've actually investigated this myself...

I don't think:

set :remote, "staging"

does what we think it does (neither did '-o staging' for that matter), it basically just renames the remote reference on the deploy server from 'origin' to whatever you choose.

Well, yes. I thought that you wanted to do this (since you used the -o option). I corrected you to move it out of the repository URL because there was already an option for it in Capistrano.

I was wrong to say that the :branch option is never used. It actually is in "recipes/deploy.rb". It uses the branch name (or "HEAD") to get the commit ID from your local repository, then uses that ID to do a remote checkout (no matter what strategy you use).

In conclusion, if you want to deploy from the "deploy" branch, you have to have that branch set up locally and all its commits pushed to your remote repository as well.

[Adam Salter]

Guys and people at large,
I've updated the Git SCM module, and it works for me...
Could some others please have a look and critique?

http://github.com/adamsalter/capistrano/commit/2283dea45a6ff15e85851136860f366c76257022

It still works for all the test cases I can think of (and almost seems
faster ;)

To see for yourself checkout my repo... I use the following command to
make changes to the gem and install:
rake repackage && sudo gem install -l --no-ri --no-rdoc pkg/
capistrano-2.3.0.gem

Thanks,
-Adam

On May 5, 11:47 pm, "Mislav Marohnić" <mislav.maroh...@gmail.com>
wrote:

> On Mon, May 5, 2008 at 2:34 AM, Adam Salter <adam.q.sal...@gmail.com> wrote:
> > I've actually investigated this myself...
> > I don't think:
> > set :remote, "staging"
> > does what we think it does (neither did '-o staging' for that matter), it
> > basically just renames the remote reference on the deploy server from
> > 'origin' to whatever you choose.
>
> Well, yes. I thought that you wanted to do this (since you used the -o
> option). I corrected you to move it out of the repository URL because there
> was already an option for it in Capistrano.
>
> I was wrong to say that the :branch option is never used. It actually is in
> "recipes/deploy.rb". It uses the branch name (or "HEAD") to get the commit

> ID *from your local repository*, then uses that ID to do a remote checkout

[Adam Salter]

Jamis,
Should I put this through as a pull request or bug for people to look
at?
I'd like to see this in Cap obviously...

-Adam

[Adam Salter]

Ok.
I've raise a Lighthouse ticket.
Can i get a few people to have a look?

http://capistrano.lighthouseapp.com/projects/8716-capistrano/tickets/14-git-scm-doesn-t-work-with-remote-branches

-Adam

On May 7, 5:54 pm, Adam Salter <adam.q.sal...@gmail.com> wrote:
> Jamis,
> Should I put this through as a pull request or bug for people to look  
> at?
> I'd like to see this in Cap obviously...
>
> -Adam
>
> On 06/05/2008, at 11:59 PM, Adam Salter wrote:
>
>
>
> > Guys and people at large,
> > I've updated the Git SCM module, and it works for me...
> > Could some others please have a look and critique?
>

> >http://github.com/adamsalter/capistrano/commit/2283dea45a6ff15e858511...