regression: git submodule update --recursive doesn't work on git 1.6 about capistrano HOT 8 CLOSED

Same issue here

from capistrano.

It was suggested that maybe it should detect the git version and act accordingly. However, it might just be simpler to just git submodule init && git submodule update, if that's equivalent like I think it would be.

The interesting thing is that git help submodule in the git 1.6.3.3 version I have says that it supports git update --init, but when when I actually do it, it acts like the syntax is bad. I can look into this more later.

from capistrano.

I couldn't find the mailing list discussion that @leehambley was referring to in the commit comments.

It might have been that the conversation was on IRC, regrettably I don't think that is logged anywhere.

I'd be happy to go back to #{git} submodule init && #{git} submodule update, if it's more portable. (it would appear to be)

from capistrano.

same problem with git 1.6.2.3

from capistrano.

After testing with --init removed, I realized that it is actually --recursive that is unsupported in earlier versions of git. That actually makes a lot more sense, since the git docs claimed to say it supported update --init in 1.6.

Git submodule update --recursive was introduced in version 1.6.5.

This would be easily worked around by adding set :git_submodules_recursive, false to the deploy.rb, except that the default is true, and set :variable, false has no effect in SCM code. I've opened pull request #103 to fix that bug.

That bug aside, to resolve this issue, we could change git_submodules_recursive to default to false, but that would likely probably break people's deploys who rely on --recursive being there by default.

Instead, we should check the git version and only use --recursive when git version >= 1.6.5. Do you guys agree with this approach? If so, I'll write the patch and submit a pull request.

from capistrano.

@nilbus nice work - that confirms what I had read. Thanks for #103, I'm sure we spoke about that previously.

Regarding the way forward, if there's a long-hand way to do this, which is backwards and future compatible, I vote to stay with it.

Preferably the Git submodule would be as agnostic as possible, Capistrano is already quite severely limited by the lowest common denominator (:copy) so I don't see why SCM support should be any different!

from capistrano.

Fixed in #105. Let me know what you think of that solution.

from capistrano.

(Pull request accepted, nice fix)

from capistrano.