Something keeps rewriting my Gemfile.lock

Question

Working on a shared project, I often find that my Gemfile.lock gets out of sync with the repository, producing error messages like:

$ git pull
Updating 1911275..8c5d26f
error: Your local changes to the following files would be overwritten by merge:
    Gemfile.lock
Please commit your changes or stash them before you merge.
Aborting

When I try to git stash the change, it doesn't work:

$ git stash
Saved working directory and index state WIP on development: 1911275 Merge branch 'development' of https://github.com/mygroup/myrepo into development
HEAD is now at 1911275 Merge branch 'development' of https://github.com/mygroup/myrepo into development
$ git status
On branch development
Your branch is behind 'origin/development' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
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

no changes added to commit (use "git add" and/or "git commit -a")

If I stash and status quickly enough, I can see that the change is getting stashed:

$ git stash && git status
Saved working directory and index state WIP on development: 1911275 Merge branch 'development' of https://github.com/mygroup/myrepo into development
HEAD is now at 1911275 Merge branch 'development' of https://github.com/mygroup/myrepo into development
On branch development
Your branch is behind 'origin/development' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
nothing to commit, working tree clean

But another status shows that Gemfile.lock has come back:

$ git status
On branch development
Your branch is behind 'origin/development' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
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

no changes added to commit (use "git add" and/or "git commit -a")

Unfortunately the same trick doesn't work with git stash && git pull; pull is too slow, and the lockfile reappears before the pull can succeed.

I thought it might be my IDE re-bundling in the background, but it happens whether or not the IDE is running. I can't find any running bundler processes, gem processes, or indeed any obvious Ruby processes of any kind.

Who or what is regenerating my file?

Can you just git ignore your lock file? I know this does not answer the question but could resolve the issue — engineersmnky, Apr 12 '17 at 22:10
tell us what is changing in the lock file. there lies the clue. — Raj, Apr 12 '17 at 22:28
@emaillenin I don't think so. It's just some random gem versions, different ones each time. — David Moles, Apr 12 '17 at 22:30
It would help if you can identify what changes have been made, perhaps via `git diff` or by looking between the `>>>` sections identifying a conflict. Newer versions of Bundler put in a version stamp, and out of sync versions can cause version control noise. — tadman, Apr 12 '17 at 22:32
@engineersmnky For reproducibility, we want the application Gemfile.lock in version control. (Cf. [this discussion](http://doc.crates.io/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries) around Cargo.lock, which plays a similar role in the Rust world.) — David Moles, Apr 12 '17 at 22:38
@tadman it's usually one line, e.g. `- jquery-turbolinks (~> 2.1.0) / + jquery-turbolinks` or `+ unf_ext (0.0.7.3) / + unf_ext (0.0.7.2)`. Whatever's causing the file to be regenerated has nothing to do with the content as such; it's just rerunning `bundle install` in a slightly different environment from the previousi checkin (or doing something else that has the same effect). — David Moles, Apr 12 '17 at 22:40
@DavidMoles I understand just a thought I mean obviously you could always lock gem versions explicitly or at least major.minor version in the Gemfile itself — engineersmnky, Apr 12 '17 at 22:40
Looks like some kind of oddball platform issue. JRuby vs. MRI Ruby? Windows vs. Linux? — tadman, Apr 12 '17 at 22:43
@tadman Nope, the whole team is on MRI and macOS, though some use rvm and some use rbenv. I think the differences are mostly a matter of timing (e.g. a new version of some gem being released in between different developers' runs of `bundle install`.) — David Moles, Apr 12 '17 at 22:45
https://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html — Matthew Schuchard, Apr 13 '17 at 12:25
@MattSchuchard (Also, no offense meant, but a comment consisting of nothing but a `cyberciti.biz` URL looks sketchy AF—I was this close to flagging as spam without clicking.) — David Moles, Apr 17 '17 at 20:29

score 22 · Accepted Answer · edited May 23 '17 at 11:54

22

Found the culprit, thanks to this answer (this answer concurs): Spring. There were half a dozen rogue spring processes on my machine, and any or all of them must have been regenerating the file. Killing those processes solved the problem, and so far adding export DISABLE_SPRING=1 to my .bash_profile seems to have kept it from recurring.

(spring stop might have worked too. I don't know whether it stops all Spring processes or just one of them, though.)

edited May 23 '17 at 11:54

Community

1
1

answered Apr 14 '17 at 15:32

David Moles

48,006
27
136
235

4

Thanks! `spring stop` did the trick for me. – dbenton Dec 23 '17 at 01:56
1

THanks a lot buddy. Ran into the same proble. U r a lifesaver – Rajesh Paul Mar 23 '20 at 08:36
3

`killall -9 ruby` ftw, so tired of spring and its meddling. – mpowered Oct 02 '21 at 01:44
1

Killing VSCode did the trick for me. – Magsafe Nov 14 '22 at 17:29
@Magsafe same here, did you found the reason? – Paul Bob Aug 17 '23 at 08:50

Something keeps rewriting my Gemfile.lock

1 Answers1