Have drush update be told to ignore a module/theme

Yeah, thats a reasonable request. Not currently possible AFAIK.

i think this could be a good feature for the drupal ports system, in the future. namely , the ability to 'lock' instances of packages.
it will also be able to detect modified packages.

What I would personally highly recommend:
Import your installation into a subversion repository.
When you need to update, don't use drush dl, but cvs update and then svn commit.
To roll out on server, just do an svn update.

If you need to manage modified versions of modules, doing so without the backing of a versioning system is dangerous and irresponsible.

Note, that update_advanced has the ability to ignore updates on certain projects (as update_status did in 5.x). We should probably check that if we can, although a .drush-ignore would be good in addition, as would a hook to allow you to wire in your own patch management checks.

we use BZR instead of SVN but the idea is the same, we also keep a log and patch files for any changes we make, so we can re-apply them when we do want to update.

However, it would be nice to be able to use drush to still update all the other non modified modules.

Marked #502660: Upgrade control over version selection (dev to/from stable and allow minor upgrades only) a duplicate of this one

Subscribing, this would be very useful, and we'd review patches. Need to get more into Drush before attempting to write the patch in the first place...

^{ben, Agaric}

Figured this one out. I've attached a very simple patch to skip any module containing a .drush-ignore file. It will pass along the following warning (in this case I used imagefield as a test):

Module imagefield has been ignored. Remove the file ".drush-ignore" from the /www/drupal6.ngphost.com/html/sites/all/modules/imagefield directory to update this module. Note that doing so will overwrite any code customizations you have made.

After removing the file and running drush update again, the update proceeds as expected.

Hmmm. i would think we would want an array that is passed in like structure-tables and skip-tables. see example.drushrc.php

That would work as long as each site can have its own config, though I do like it being as easy as "touch sites/all/modules/modulename/.drush-ignore" rather than having to create a whole PHP file. Also, I'm having a hard time figuring out how those config options actually get referenced within Drush.

you can put a drushrc.php in each multisite. this is described at the top of example.drushrc.php. the options in this file are loaded very early in the drush request. fire up your friendly debugger and step through drush. its a great movie.

subscribing, would like this too.
thank you sean for the solution-for-now!

The use cases for drushrc restrictions on upgrades and the suggested .drush-ignore seem different.

In the case of a multisite install with a hacked module in sites/all/modules/mymodule, the .drush-ignore fix will allow easy protection of the hacked module for all sites.

To achieve the same end for a module in sites/all/modules, the .drushrc.php exclusion will need to be done in the Drupal installation root. (My preference is to keep the core Drupal codebase unchanged and make modifications only in sites/*, and using .drush-ignore will allow this where using drupal-x.xx/drushrc.php won't.)

If placed in sites/example.org/drushrc.php, update of another instance on the same multisite might affect a shared module unless the exclusion is added to all sites/*/drushrc.php

If placed in ~/.drushrc.php or Drush install folder, the exclusion would apply to all multisites on the server.

I don't disagree with Moshe's suggestion that we add an $options array to protect modules, but I would like to see support of both that and the .drush-ignore approach in Drush, because I think that .drush-ignore has a valid use case (simple preservation of hacked modules without need to maintain extra files in the Drupal install dir).

I can't see how that same result can be achieved via drushrc.php at present?