78

I have a project with certain js files which I cannot update. I run OSX locally and my remote/staging server is Linux (CentOS).

Right after cloning my project locally, i noticed I have all those files with git status modified. I never modified them, so I tried to discard changes or reset them, but they come up again. The change that is in the modification is deleting all lines and adding them again.

I'm not sure why this happens or how to fix it so that my git status is clean as it needs to be.

Here is a few lines from the git status:

#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/el.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/fa.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/gu.js

UPDATE 1:

I have now managed to commit the above files, but the staging server is locked because it won't pull new edits:

error: Your local changes to the following files would be overwritten by merge:
    app/webroot/js/ckeditor/_source/lang/ar.js
    app/webroot/js/ckeditor/_source/lang/bg.js
    app/webroot/js/ckeditor/_source/lang/bn.js
    app/webroot/js/ckeditor/_source/lang/cs.js
    ...
Aborting

I can't commit/push because:

Updates were rejected because a pushed branch tip is behind its remote counterpart

I tried:

git reset --hard

and

git stash
git stash drop

But they don't work, nothing happens.

UPDATE 2:

git diff gives me:

The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/fa.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/gu.js.
The file will have its original line endings in your working directory.
...
AD7six
  • 63,116
  • 12
  • 91
  • 123
mgPePe
  • 5,677
  • 12
  • 52
  • 85
  • If the files are shown as modified over and again, please check if there are any differences like newline, control characters etc. between your local files and repository files. – Shunya Aug 31 '13 at 08:48
  • No, there aren't. It would have shown only 1 line change as opposed to all lines. Also if there were any real changes, I should be able to discard them, which it is not working in this case. – mgPePe Aug 31 '13 at 09:09
  • http://stackoverflow.com/questions/2016404/git-status-shows-modifications-git-checkout-file-doesnt-remove-them – Ohad Schneider May 03 '16 at 09:49

4 Answers4

118

Normalize line endings

The change that is in the modification is deleting all lines and adding them again.

This is because the newlines are being changed between the committed files and the files on disk.

Github has a handy page detailing how to deal with this kind of problem, in brief (for linux/OSX), step one is to change your git config so it sorts out the line endings for you:

git config --global core.autocrlf input

Then commit line-endings normalization:

git rm --cached -r .
# Remove everything from the index.

git reset --hard
# Write both the index and working directory from git's database.

git add .
# Prepare to make a commit by staging all the files that will get normalized.
# This is your chance to inspect which files were never normalized. You should
# get lots of messages like: "warning: CRLF will be replaced by LF in file."

git commit -m "Normalize line endings"
# Commit

And then, line endings should be handled correctly. See the help page on github for more information, or the relevant section of the git docs formatting and whitespace.

Resolving linux-machine conflicts

the staging server is locked because it won't pull new edits.

The error message reads "Your local changes to the following files would be overwritten by merge:", that means they contain local changes which should either be committed or discarded before continuing. Assuming normal usage for the staging server (it doesn't have any intentional changes) the local changes can be discarded. For example do the following:

$ git fetch origin
# Retrieve updates

$ git reset --hard origin/master
# Forcibly change the current branch to match origin/master

This will retrieve the repository history, without updating the working copy, and then update to exactly match the master branch in the repository. Note that the last command will discard all uncommitted changes.

Community
  • 1
  • 1
AD7six
  • 63,116
  • 12
  • 91
  • 123
  • Thank you! Such a full answer, and you took care of the commit conflict! – mgPePe Sep 18 '13 at 15:35
  • 1
    You just saved me an afternoon of hurt. – Jerry Brady Jan 27 '14 at 21:38
  • I am getting a similar issue but with images. Do you think it would be related to this answer? – Will Jun 19 '14 at 09:17
  • Maybe - what's the difference: line endings, executable or something else? For any response beyond "yeah that was it" -> ask a question referencing this one. The relevant difference, if there is a difference, is that image files are binary and so shouldn't be affected by anything line-ending related. – AD7six Jun 19 '14 at 09:27
  • 1
    We had a well-meaning team of contractors add the .gitattributes with all the line ending normalizations turned on. This caused confusion for developers when they could not switch branches because this corrupts the index. This answer helped us clear cache and rebuild the index (git rm --cached -r . AND git reset --hard), but the best solution for us was to delete the .gitattributes altogether so that everything worked the way it did before they changed it. – neoscribe Feb 08 '16 at 19:22
  • Any idea why this pops up? I've seen this pop up in a repo i've been using for months without any changes. I'd really just like to tell it to not mark the files as changed (since I haven't changed them...). – Michael Haefele Apr 20 '17 at 17:30
  • If the problem is related to file execution, you need this instead: `git config core.filemode false` – phyatt Mar 11 '22 at 22:08
15

I always mentioned making sure that your core.autocrlf is set to false, as in "Git : stuck repo using stash after crlf normalization?"

git config --global core.autocrlf false

Also make sure that you don't have a .gitattributes file with eol directives that would try to convert the end-of-lines.
The basic idea is: do you still see that error message when you make sure there is no automatic conversion of any sort?

But just in case, consider also "Git rebase fails, 'Your local changes to the following files would be overwritten by merge'. No local changes?"

I'm on a mac, and this obscure config change seemed to fix all my woes regarding unstaged changes when there were none.

git config --global core.trustctime false
Brent Bowers
  • 103
  • 1
  • 3
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 2
    good advice. Most appropriate if there is no windows user collaborating to bork the newlines, or if problems are only with vendor files. However if there _is_ a mixed team of windows + mac/linux users - this will cause perpetual whitespace changes depending on who touched the file last. +1. – AD7six Sep 19 '13 at 09:20
  • 1
    Thanks for the *.gitattributes* info. Didn't know about it. In my case that was the reason I couldn't discard changes. Now problem solved! – informatik01 Jan 14 '16 at 11:25
  • 1
    .gitattributes file with eol was my case. Thanks! – JohnnyFun Mar 20 '19 at 22:18
15

I just spent 2 hours (!) on the same issue with a .svg file (Scalar Vector Graphics), which kept changing after 'revert' without my intervention.

So the file shows up as modified in 'git status'; reverting it succeeds, but it keeps changing, so the 'pull' is failing again and again.... so annoying!

No luck with 'git reset', 'git ignore', 'git untrack' etc...

Finally, I solved it by removing the file from my local system (not 'git delete', just Shift + Delete) >> now 'pull' request passes, and the file is fetched from the remote repository.

So easy, I could cry!

Naor Bar
  • 1,991
  • 20
  • 17
5

This issue repeatedly popped up with the Roll20 character sheets repository on an Ubuntu machine and I could solve it by 

#!/bin/sh

# Use in root dir of git repository
# Fixes some newline-related weirdness
git rm --cached -r .
git reset --hard

But, this stopped resolving the issue completely today and by looking around Stack Overflow I found the culprit to be their .gitattributes file:

# Auto detect text files and perform LF normalization
* text=auto

After git pull origin master, git status returned:

On branch master
Your branch is up-to-date with 'origin/master'.
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:   Star Wars Revised RPG/SWRRPG-updated.html

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

The solution was to remove the * text=auto line from the .gitattributes:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
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:   .gitattributes

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

The changes on .gitattributes can be discarded and Git will still be satisfied.

Edit +1d: Retried the .gitattributes "trick" today, but did not git status before discarding the .gitattributes changes. For no reason obvious to me (maybe caching of git status?), a git status afterwards returned this again:

On branch master
Your branch is up-to-date with 'origin/master'.
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:   Star Wars Revised RPG/SWRRPG-updated.html

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

Doing it again, but with git status inbetween worked.

Kreuvf
  • 273
  • 3
  • 6