GIT keeps introducing uncomitted changes on checkout

Question

I have created a new repository in BitBucket Server, and it is populated and in use. However, several of our users (myself included) are having a problem where unexpected changes are appearing on checkout. It does not appear on every checkout, only sporadically.

The changes appear to be a complete rewrite of the file(s) in question. git diff does not show, for example, that all line endings have changed. We are also using SVN Mirror to bring in changes from our older subversion repository on trunk -> master. Everyone is using 2.14 version of git on Windows.

The following commands will fix it temporarily, but it inevitably comes back

git rm --cache -r
git reset --hard

Example:

MINGW64 /c/code/git/repo (master)
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

MINGW64 /c/code/git/repo (master)
$ git checkout -
Switched to branch 'dev/test_branch'

MINGW64 /c/code/git/repo (dev/test_branch)
$ git status
On branch dev/test_branch
nothing to commit, working tree clean

MINGW64 /c/code/git/repo (dev/test_branch)
$ git checkout -
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

MINGW64 /c/code/git/repo (master)
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

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:   <snip-filename>.java
        modified:   <snip-filename2>.java
 ... etc ...
        modified:   <snip-lastfilename>.java

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

Edit: Checking git diff -w to exclude whitespace changes shows no differences, so it definitely appears to be eol related.

Have you diff'd the changes? It could be file permissions. If so, see https://stackoverflow.com/questions/1580596/how-do-i-make-git-ignore-file-mode-chmod-changes. — steadweb, Nov 10 '17 at 15:29
When I use git diff it is showing as similar to @@ -1,539, ~1,539 @@ -- + + How would I tell from this if it is file permissions please? — SmurfTheWeb, Nov 10 '17 at 15:43
Ah, I don't think that's permission issues, as you won't have code changes in the diff, you would see what the file permissions where of each file before and after. Could it be file encoding? — steadweb, Nov 10 '17 at 15:46
They're just standard java code, there is nothing special about them. The files showing as uncommitted do appear to be files that have recently had commits (on origin) — SmurfTheWeb, Nov 10 '17 at 15:48
If it helps, they do not show up as unstaged changes or staged changes in Eclipse. They do show up as unstaged changes in SourceTree. git reset --hard does not get rid of them. — SmurfTheWeb, Nov 10 '17 at 15:56
This really does look like CR/LF line ending issues, or perhaps some sort of related clean/smudge item. It's possible someone mistakenly committed the files with actual CR-LF endings inside them, and *your* Git is cleaning that up, replacing the endings with LF-only, which then shows up as a diff even though you are doing everything right. — torek, Nov 10 '17 at 18:35
Would it make a difference that the files that are affected seem to be coming from the SVN mirroring? (Just wondering if the line endings are not being fixed when it picks up the SVN changes). If this is the case, how could I resolve it (I don't mind turning off line ending change, at least until we drop SVN in a week) — SmurfTheWeb, Nov 13 '17 at 09:24
sounds to me like *We are also using SVN Mirror to bring in changes from our older subversion repository on trunk* is the culprit but it's hard to say. — Liam, Nov 14 '17 at 11:45

SmurfTheWeb · Answer 1 · 2017-11-23T10:44:29.503

For this issue, it ended up being due to Subversion mirroring. When enabled, the line endings coming from Subversion were not corrected automatically, and so had their original eol. With the GIT repository set either through .gitattributes, or through a user's default settings, to automatically correct line endings, this would cause a mismatch where the original line ending was CRLF, and the updated version just LF.

This was identified by using

git diff --ignore-space-at-eol

which showed no differences to the previous version.

The solution was to commit and push the line-ending adjusted files into GIT. This then mirrored to Subversion, and put them back into sync again.

For more information, I found a very useful guide here: https://help.github.com/articles/dealing-with-line-endings/

GIT keeps introducing uncomitted changes on checkout

1 Answers1