Troubles with git and Gemfile.lock

Question

I keep running into the following error with my Gemfile.lock whenever I want to do a git pull or checkout a new branch.

error: Your local changes to the following files would be overwritten by merge:
    Gemfile.lock
Please, commit your changes or stash them before you can merge.
Aborting

The problem is that I can't figure out how to fix it.

• Stashing the file doesn't work -- the local changes just stay there for some reason.
• I've also tried running git checkout -- Gemfile.lock to discard the changes, but that doesn't work either -- the local changes just stay there.
• I've also tried creating a new branch and committing the Gemfile.lock changes just to that branch... but that doesn't work either. The changes remain!

What do I need to do? I've gone so far as to just clone a new git repo, but soon enough, all this starts happening again.

Answer 1

After doing the following, I was able to pull and check out branches again.

git checkout Gemfile.lock
git reset --hard HEAD

I'm not sure why and how this solution works. Explanations are welcome.

The reason git was detecting Gemfile.lock as modified in my case, was that the bottom of the file had BUNDLED WITH 1.10.3. After updating bundler gem update bundler, regenerating and committing Gemfile.lock, it stopped appearing in git as modified.

git version 2.2.1, Mac OSX version 10.10.4, iTerm2 Build 2.9.20150624-nightly (w/shell integration)

Answer 2

This happened to me and git reset --hard HEAD from the accepted answer didn't help. However, running spring stop did the trick. I suspect spring is rewriting the file whenever it is modified to ensure that it is in sync with the code running via spring.

Answer 3

You are not able to checkout Gemfile.lock since spring is running in the backend to sync your code in developement environment. If you want to checkout, firstly stop the spring processes. You can stop spring in two different ways.

1. Either you just stop spring using command in the terminal

spring stop

2. Or by manually killing the processes of spring running on local, just like

   ps -aef | grep spring
   kill -9 pid
   

Both looks good to me. Choose what's better for you!