> Quick Q: my production deployment should go on a specific version of
> my repository, therefore I keep placing tags whenever I think it's
> time again to push an update. Now apparently these tags do exist on
> the remote (github) repo as I can see them in the github interface
> aswell as when doing a git ls-remote:

> macPro:dw-backend joerg$ git ls-remote g...@github.com:joergbattermann/
> dw-backend.git v0.2.1
> db6491672974bb4fefd06724231e779c63b0744d        refs/tags/v0.2.1

> Now when I want to deploy via capistrano, I have the following set in
> my deploy.rb:

> set :branch, "v0.2.1"
> set :rails_env, :production

> ... looking at the output of cap deploy I get an error pretty early in
> the whole process:

> cap production deploy
>   * executing `production'
>     triggering start callbacks for `deploy'
>   * executing `multistage:ensure'
>   * executing `deploy'
>   * executing `deploy:update'
>  ** transaction: start
>   * executing `deploy:update_code'
>     executing locally: "git ls-remote g...@github.com:joergbattermann/
> dw-backend.git v0.2.1"
>   * executing "git clone -q --depth 1 g...@github.com:joergbattermann/
> dw-backend.git /home/rails/dw/releases/20090118142245 && cd /home/
> rails/dw/releases/20090118142245 && git checkout -q -b deploy
> db6491672974bb4fefd06724231e779c63b0744d && git submodule -q init &&
> git submodule -q update && (echo
> db6491672974bb4fefd06724231e779c63b0744d > /home/rails/dw/releases/
> 20090118142245/REVISION)"
>     servers: ["dw.se"]
>     [dw.se] executing command
>  ** [dw.se :: out] remote: Counting objects: 242, done.
> remote: Compressing objects:   1% (2/182)
> remote: Compressing objects:  19% (35/182)
> remote: Compressing objects:  37% (68/182)
> remote: Compressing objects:  41% (75/182)
> remote: Compressing objects: 100% (182/182), done.
>  ** [dw.se :: out] remote: Total 242 (delta 61), reused 187 (delta 40)
>  ** [dw.se :: out] git checkout: updating paths is incompatible with
> switching branches/forcing
>  ** Did you intend to checkout
> 'db6491672974bb4fefd06724231e779c63b0744d' which can not be resolved
> as commit?
>     command finished
> *** [deploy:update_code] rolling back
>   * executing "rm -rf /home/rails/dw/releases/20090118142245; true"
>     servers: ["dw.se"]
>     [dw.se] executing command
>     command finished
> failed: "sh -c \"git clone -q --depth 1 g...@github.com:joergbattermann/
> dw-backend.git /home/rails/dw/releases/20090118142245 && cd /home/
> rails/dw/releases/20090118142245 && git checkout -q -b deploy
> db6491672974bb4fefd06724231e779c63b0744d && git submodule -q init &&
> git submodule -q update && (echo
> db6491672974bb4fefd06724231e779c63b0744d > /home/rails/dw/releases/
> 20090118142245/REVISION)\"" on dw.se

> Any idea what I'm doing wrong or what I could do?

> Cheers,
> -J

> Just gave it a try with a real remote branch & it's working... with
> tags it wasn't.. hrm :-/

> On Sun, Jan 18, 2009 at 16:22, Jörg Battermann <j...@joergbattermann.com>wrote:

> > Just gave it a try with a real remote branch & it's working... with
> > tags it wasn't.. hrm :-/

> Hello Mislav,

> yep... just double checked:

> macPro:dw.se-backend joerg$ git push --tags
> Everything up-to-date

> > Hello Mislav,

> > yep... just double checked:

> > macPro:dw.se-backend joerg$ git push --tags
> > Everything up-to-date

> Well, my suggestion was stupid because you don't need to push tags to deploy
> a tag. Capistrano resolves branch/tag names *locally* on your machine and
> later uses the raw SHA1 in the deployment process. You have to make sure
> that the branch this commit is part of is pushed to your repo.

> If it is, and apparently you've made sure it's fine, I can't really tell
> what's the problem.