Ask user if they want to revert local changes when an update is blocked #466

Seldaek opened this Issue Mar 16, 2012 · 14 comments

8 participants

Composer member

Currently Vcs-downloaders throw an exception if the dir to be updated isn't in a clean status, but asking (if in interactive mode) and then reverting for the user if he answers yes would be nicer.


This is particularly useful after debugging sessions where some code is left over inside the vendor dirs since a git status on the project won't show those modified files. Currently we're using an adapted git status which allows us to do a recursive git status on each Vcs-enabled vendor dir to detect for those changes.

Works, but not as handy as an interactive prompt.


somewhat related, i would love to have a command in composer that shows me which vendors have local changes. if i fix a bug that goes over multiple vendors, i often have a hard time figuring out which repos i have to push.


as a workaround for detecting what changed, i hacked this script:


From #807, silently revert if you run with -n (--non-interactive).


the silently revert sounds scary - i would think about adding a --force-revert option or something for people using non-interactive and expect to have local changes. the problem is that the reverting can really lead to data loss so we have to be careful.

Composer member

If you run -n IMO you can expect this kind of behavior, you would typically not do that on a machine where you're working, so I don't see the problem. In interactive mode it would ask you, which I think is easier (because a --force-revert option means you have to think before calling the command, and then you have to start all over if it fails)


Using the non interactive option still results in a hard fail though.

I'm using capistrano for deployments so the interactive prompt causes the release to stall. Is it possible to make the default option '-y' for the question 'Discard changes [y,n,v,s,?]?' when running in non-interactive mode?

Composer member

For capistrano you should use --no-interaction, and yes it'd make it fail but if you edit your vendors on production it sounds like you're doing something wrong no? Adding a -y switch is not impossible but it's hard to say what -y should apply.. for now we only have that but maybe in the future there are other stuff that'll ask for your confirmation.


I think it was work left over from us trying to debug an environment specific issue (this was in our staging environment) relating to an i18n issue.

I saw that capistrano flag but thought it only applied to capistrano tasks (rather than other scripts that those tasks may call). I look into seeing if I can amend our composer task to use the same flag as capistrano, and find some way to have the prompt question answered automatically when --no-interaction is in use.

edit: thanks for your input


@calumbrodie --no-interaction is a symfony/Console feature. It applies to any project based on the Console component (except if they are explicitly disabling it)

@Seldaek Seldaek closed this Jan 11, 2013

this should really have this --force-revert facility... otherwise how I can update my vendors... When running capifony for example, I know what I am doing executing this.

People should not have local changes in vendors folder anyway... or maybe there is a better way of handling this but as it is now it makes impossible to update vendors on production via non interaction mode (capifony)

as for now the only way is to dump all vendors on production and rerun composer.phar install ... not ideal at all ;S


@rat4m3n we successfully deploy with capifony using

set :deploy_via,  :copy

plus the stuff described in

as written above, you really should not edit code on a production system. if you did, you still have the option of disabling the copy in your capifony, or if you don't care about the outage anyways just delete the vendors (at least those that changed) to have composer reinstall. see also the gist i posted somewhere up in this thread to do git status recursively - helps a lot to find where things changed.

btw when developping things where each bundle is its own repository (like the Symfony CMF) i tend to have a lot of changes in my vendors so i can develop and test integration in parallel.


@dbu wow this is interesting.... I thought I am using copy method but slightly enhanced using set :deploy_via, :rsync_with_remote_cache

Thanks for your tip!

This setup works if your vendors changed:

    set :deploy_via, :copy
    # set :deploy_via, :rsync_with_remote_cache
    set :use_composer, true
    set :composer_options,  "--verbose --prefer-source"
    set :update_vendors, false
    set :copy_vendors, false

For those who found this on Google:

Use .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment