CODEWITHSUNDEEP
git
SmurfTheWeb
SmurfTheWeb

Reputation: 93

GIT keeps introducing uncomitted changes on checkout

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.

Upvotes: 0

Views: 84

Answers (1)

SmurfTheWeb
SmurfTheWeb

Reputation: 93

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/

Upvotes: 1

Related Questions