Category Archives: git

Warning: LF would be replaced by CRLF fixed by dos2unix

If you work with the version control system git, and you work with people that use a multitude of development environments and operating systems, you are bound to run across the warning, “LF would be replaced by CRLF.”

There are many ways to fix this, but my favorite is a utility called dos2unix. You feed the command line utility the file to convert and dos2unix does the rest. If you are using homebrew on the mac you can run

brew install dos2unix

Other operating systems support the utility as well, the Windows app store even has a dos2unix utility.

Once you have it setup you simply pass the offending file to the utility and then proceed on with your day.

dos2unix config.rb

You can pass it multiple files if you wish to do batch conversion. Once you receive no more warnings you can continue on with a git commit.

How-to: Use git to update Drupal when you can’t use Drush


You have code on a production server that does not allow Drush to be running and you do not enjoy the idea of copying over live files. If these sites are already tracking a git repository that is great, simply do a push and pull and you are done. It gets more complicated though if the repositories are woefully out of sync or if they have never had a git repository configured.

Proposed Solution:

The solution I devised allows you to update the site locally, make a nice commit, and then fetch it on the remote server and reset the filesystem to the fetch that was just made. Here are the steps:

  1. Create a git repository within your development site (skip this step if you already have git enabled).
    $git init
  2. Use Drush on your development site to update Drupal core.
    $drush pm-update drupal
  3. Test your site and then add and commit the files you have just updated.
    $git add -u
    $git commit -m"Upgrade to Drupal version x.yz"
  4. Create a remote repository if you do not have one already configured. Once that is created link your development repository to the remote and push your updates.
    $git remote add origin RemoteRepositoryURL
    $git push origin master
  5. Now, go over to your production site and create a git repository like in step 1 above. Next, you will add the remote, fetch the update from that remote, and then reset your file tree to what you just pulled with the following commands.
    $git init
    $git remote add origin RemoteRepositoryURL
    $git fetch --all
    $git reset --hard origin/master
  6. That last command will rebuild the file system based on repository and from now on you can do normal push and pulls. Make sure to run update.php to get your database in sync with the new Drupal release.


I know the above is quite unorthodox. You also need to be careful as it will only rebuild the files you are tracking. I do not normally advocate for tracking entire Drupal installs but if you are in a situation as detailed above, it may be one of the few ways to have a sane update mechanism. For working with remotes I find the git-scm reference pages very handy.