I'm the guilty party involved, and apologize for slipping that error into a largeish patch at the last minute. Only while testing the installer have I started working with actual command-line use of patch and diff, and have forgotten to move my default settings file a couple of times. I, too, (usually!) just cvs diff and manually remove the cruft. Thanks for the reminder. It is, indeed, very important. :) --Jeff -----Original Message----- From: Jeremy Epstein [mailto:jazepstein@gmail.com] Sent: Wednesday, August 02, 2006 10:05 PM To: Drupal devel Subject: [development] Patching settings.php Hi guys, I've noticed that the past 2 commits to settings.php were both made inadvertently, due to someone including a settings.php $db_url change in their patch by mistake. As you can see, both of these commits had to be reverted: http://drupal.org/cvs?file=/sites/default/settings.php Can I request that all of the patch authors among us (including myself) _please_ check your patch files, and that you ensure that there are no custom settings.php $db_url (or other) changes that have slipped into your patch. I think that the primary responsibility for this should lie with patch authors. However, it would be good if the core committers could be on the lookout for accidental settings.php changes in patches as well. If anyone has any tips for excluding settings.php from a patch, that would be greatly appreciated. Personally, I just run "cvs diff -u > foo.patch" from the root Drupal install dir, and then manually edit the file to remove the settings.php cruft. I'm sure there's a better way to do it. ;-) The biggest problem that I have with accidental settings.php changes, is that running "cvs up -dP" after such a change results in CVS complaining about a conflict/merge in settings.php, even though the change was reverted. So let's try and keep _intentional_ settings.php changes to a minimum (which we seem to be doing quite well at), and keep _accidental_ settings.php changes to zero. Thanks, Jaza.