Gemfile.lock always has changes not staged for commit

I am running into this problem on a rails app I am working on. I was working on a feature branch and wanted to rebase from the most recent master. I ran the following commands:

$ git checkout master
$ git pull --rebase

If I try to checkout back to my feature branch I get the following error:

  • When running Bundle against local Gems, what steps must be taken to make the new Gem code take effect?
  • Bundler error: Retrying git cat-file … If this error persists you could try removing the cache directory
  • Developing gems and using them in rails projects with bundler, is there a faster way?
  • Error while fetching git file using Bundler
  • How to use gem from GitHub on Heroku?
  • Using Bundler with Git, is https:// or git:// better?
  • Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)
      modified:   Gemfile.lock

    I have tried the following commands to resolve the Gemfile.lock back to aster with none of them being successful:

    $ git checkout -- Gemfile.lock
    $ git stash
    $ git reset HEAD --hard

    Every time I run a new git command I go back to the Gemfile.lock having changes not staged for commit.

    Here are the following versions of libraries I am working with:

    $ git --version => 2.3.3
    $ bundler --version => 1.7.9

  • Bitbucket webhooks automating releases
  • git-svn local branch tracking remote svn branch
  • Can EGit (Eclipse git plugin) use an SSH key instead of a username and password?
  • How to commit a long Git merge in the middle of resolving conflicts
  • Creating new branch in github but it isn't current?
  • git: fatal: Could not read from remote repository
  • 2 Solutions collect form web for “Gemfile.lock always has changes not staged for commit”

    There must be some process running in the background or some side-effect of executing the git commands in your shell that is modifying the Gemfile.lock.

    I am not familiar with rvm’s magic (although that sounds plausible); here are some other things to check:

    • In recent versions of Rails there is a “spring” background process that runs. Try running spring stop (or bin/spring stop or bundle exec spring stop) to gracefully terminate that process.
    • Likewise if you have any other Rails-related processes like rails server, guard, zeus, sidekiq, etc. running, try shutting those down.
    • You might be running a git pre-commit hook. Check the .git/hooks directory.
    • git might be an alias in your shell for another command. Run alias to see a list of shell aliases.
    • Your shell prompt might be executing code to do things like show the current git status and branch name in the prompt. This code would be executed after every shell command to redraw the prompt, and might have side-effects. Check your .bashrc or .bash_profile.

    There are times that running a rails command or other bundle exec command will silently update your Gemfile.lock. I am guessing you are doing that sometime in between your git commands. Or you have something weird installed that does that invisibly.

    (Could rvm do this invisibly? I don’t know. I think rvm does all kinds of odd stuff and don’t use it.).

    At any rate, the fact that this is happening is probably evidence of something else going on that isn’t what you want — are you sure the Gemfile and Gemfile.lock you are trying to commit together are actually compatible? Normally any time a Gemfile changes at all, it is wise to run bundle install to get a new Gemfile.lock. If you are trying to commit a Gemfile.lock which actually isn’t compatible with the Gemfile… I am not sure why you would want to do that anyway, normally I want the Gemfile and Gemfile.lock in any given commit to be compatible.

    To get a clue as to why something (mysterious) may be changing your Gemfile.lock, do a git diff on the Gemfile.lock to see how it’s changed?

    Git Baby is a git and github fan, let's start git clone.