Rails 3.2: ¿Por qué mi twig maestra ve la joya capistrano-stats de mi twig de actualización rails4 y puedo implementar master?

He estado trabajando en una twig de rails4 desde hace un time, actualizando la aplicación de Rails 3.2 a Rails 4.2. Mientras tanto, me di count de que algunas cosas que anteriormente se habían fusionado en el master nunca se implementaron, así que cambié de nuevo a cap production deploy master y ejecución de cap production deploy .

De repente, obtuve este post de Capistrano que nunca había visto antes:

 MBA:myapp david$ cpd Would you like to enable statistics? Here is an example message we would send: 1|2015-01-21T10:59:17-05:00|1.9.3|x86_64-darwin14.0.0|3.3.5|c52f7ecf 

Como se mencionó anteriormente, nunca recibí este post cuando lo implementé anteriormente. Aquí está mi Gemfile.lock para capistrano en master :

 capistrano (3.2.1) i18n rake (>= 10.0.0) sshkit (~> 1.3) capistrano-bundler (1.1.3) capistrano (~> 3.1) sshkit (~> 1.2) capistrano-rails (1.1.2) capistrano (~> 3.1) capistrano-bundler (~> 1.1) 

… y en rails4 :

  capistrano (3.3.5) capistrano-stats (~> 1.1.0) i18n rake (>= 10.0.0) sshkit (~> 1.3) capistrano-bundler (1.1.3) capistrano (~> 3.1) sshkit (~> 1.2) capistrano-rails (1.1.2) capistrano (~> 3.1) capistrano-bundler (~> 1.1) capistrano-stats (1.1.1) 

Noto de inmediato que capistrano-stats existe en Gemfile.lock para la twig rails4 pero no en master . Sin embargo, sigo recibiendo el post de statistics al implementar el master , incluso si ejecuto la bundle install en la twig master antes de implementar.

¿Puede alguien explicar cómo esto está funcionando con Git, y cuáles serían las consecuencias de desplegar el master en este punto ya que parece estar viendo cosas (gems) de la twig rails4 aunque no lo haya fusionado?

Si está implementando el master , pero ha revisado la twig rails4 en git local, todavía está implementando usando su configuration local (desde la twig rails4 ).

Esto se debe al hecho de que capistrano no revisa la twig que desea implementar localmente, solo en el server en el que está implementando y la configuration se carga antes de que esto se realice.

ACTUALIZAR

Descubrimos que ejecutar con y sin bundle exec ejecuta diferentes versiones de capistrano (con bundle exec siendo el correcto).

Si tiene más versiones de capistrano, puede suceder que se select el no local, pero el que tiene la versión más alta lo hará.

Para resolver eso, puede generar un binstub para su capistrano con bundle binstub cap ; luego verás que se ha agregado un ejecutable (como ./bin/cap ) y si agregas ./bin a tu PATH , podrás ejecutar sin bundle exec nuevamente.