brew update: The following untracked working tree files would be overwritten by merge:

Don't forget to fetch the origin:

cd /usr/local/Homebrew
git fetch origin
git reset --hard origin/master

What happens is that you are trying to update brew, but brew itself is either not up to date (likely), there is a permissions change via some OS update (also likely), or brew is slightly corrupt (unlikely). Since brew itself is a git repo, you have to update or reset brew to the master branch version. brew [by default] is located in the /usr/local/Homebrew folder, so you

1. Go to that folder [first command] which also should update permissions (if not see below)
2. Fetch the origin [second command] which means to update your LOCAL version of the remote branch of brew
3. Hard reset [3rd command] based on the REMOTE master branch (which also uses your current permissions).

You can also chown the first command if you are in a non sudo or admin profile

sudo chown -R `whoami` /usr/local/Homebrew
cd /usr/local/Homebrew
git reset --hard origin/master

To understand git reset, take a look at this article.

I had a similar issue a couple weeks ago trying to update an old homebrew install. Doing this:

git reset --hard origin/master

in /usr/local fixed it for me.

It seems like other folks have had this issue too. Have you looked over any of the proposed workarounds here?

I'm adding my personal experience, since it seems a little safer than what proposed in 2012:

1. Run brew doctor.

2. If you get the following warning:

   Warning: The /usr/local directory is not writable.
   

   run:

   sudo chown -R `whoami` /usr/local
   

   to fix the permissions problems (as suggested also by Chris Frisina). Eventually run brew doctor again to ensure yourself that the warning is gone.

3. Now, you should have a

   Warning: You have uncommitted modifications to Homebrew
   

   that may bey solved by

   cd /usr/local/Library && git stash && git clean -d -f
   

   as suggested by Dr.Brew itself. The command stashes the uncommitted modifications so you could go back and recover them if needed. It seemed safer than git reset --hard origin/master to me.

4. If you wish, check the official troubleshooting guide if the steps suggested here and by other SO users does not solve your problem.