4

I have a strange git problem. After checking out one of the branches (that is remotely tracked) I instantly get modified and unstaged changes in that branch. I have cloned the repository again to verify the problem still exists.

I am using Windows and gitblit as Git server.

Do you have any ideas why this could happen?

The output of git status is as follows:

$ git status
# On branch RSD-5393
# 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:   apis.releng/cquery/apis.RSD-4780.cquery
#       modified:   apis.releng/cquery/apis.RSD-4782.cquery
#       modified:   apis.releng/cquery/apis.RSD-4786.cquery
#       modified:   apis.releng/cquery/apis.RSD-4799.cquery
#       modified:   apis.releng/cquery/apis.RSD-4812.cquery
#       modified:   apis.releng/cquery/apis.RSD-4815.cquery
#       modified:   apis.releng/cquery/apis.RSD-4821.cquery
#       modified:   apis.releng/cquery/apis.RSD-4823.cquery
#       modified:   apis.releng/cquery/apis.RSD-4826.cquery
#       modified:   apis.releng/cquery/apis.RSD-4827.cquery
#       modified:   apis.releng/cquery/apis.RSD-4828.cquery
#       modified:   apis.releng/cquery/apis.RSD-4829.cquery
#       modified:   apis.releng/cquery/apis.RSD-4831.cquery
#       modified:   apis.releng/cquery/apis.RSD-4846.cquery
#       modified:   apis.releng/cquery/apis.RSD-4861.cquery
#       modified:   apis.releng/cquery/apis.RSD-4862.cquery
#       modified:   apis.releng/cquery/apis.RSD-4863.cquery
#       modified:   apis.releng/cquery/apis.RSD-4864.cquery
#       modified:   apis.releng/cquery/apis.RSD-4865.cquery
#       modified:   apis.releng/cquery/apis.RSD-4866.cquery
#       ....
no changes added to commit (use "git add" and/or "git commit -a")

.gitconfig:

[core]
autocrlf = true

.gitattributes in repository:

# Set the default behaviour, in case people don't have core.autocrlf set.
* text=auto
ri5b6
  • 370
  • 1
  • 10
  • Could you post the output of `git status` after you've checked out the branch please? – Adam H Sep 09 '14 at 11:12
  • I did add some of the modified statements of the git status output. – ri5b6 Sep 09 '14 at 11:27
  • Is it possible that you've got some other tool (such as an IDE) which is modifying these files after you've checked out the branch? – Adam H Sep 09 '14 at 11:32
  • I used TortoiseGit to clone the repository and from there the Git Bash. Eclipse IDE is closed. – ri5b6 Sep 09 '14 at 11:35
  • 2
    Can you try a `git config --global core.autocrlf false`, and clone again, to see if the issue persists? – VonC Sep 09 '14 at 11:42
  • Yes the problem persists. I changed the core.autocrlf setting, then cloned the repository again and checkoud out into the branch. same behaviour. I will add my git config to the question – ri5b6 Sep 09 '14 at 11:46
  • 2
    Maybe you have a `.gitattribute` file in the repository with a smudge filter? – Sascha Wolf Sep 09 '14 at 11:47
  • the autocrlf setting was set to "true" originally, but I also tried it with "false" as mentioned – ri5b6 Sep 09 '14 at 11:48
  • .gitabbtributes posted as well – ri5b6 Sep 09 '14 at 11:56
  • 3
    @ri5b6 then try and remove the * text=auto directive (add and commit just that modification, push, then re-clone). – VonC Sep 09 '14 at 12:00
  • I did and had the same problem. What I did now is just added the modified files again to the index and try to work with it as described here: https://help.github.com/articles/dealing-with-line-endings – ri5b6 Sep 09 '14 at 12:14

1 Answers1

1

There are multiple reasons this could happen.

  1. You have the core.autocrlf setting enabled
  2. You have a .gitattributes file which has a smudge or text filter

Some background

autocrlf trys to handle the line-ending difficulties of cross-plattform development but often leads to more problems than it solves.
It converts windows style line-endings (\r\n) to unix style ones (\n) when adding files to the repository. While working on a windows machine it converts them back into windows style line-endings when checking files out.

Although the general idea isn't bad, it can lead to serious problems, especially when it runs amok on binary files. So most of the time it's a wise choice to handle line endings yourself.

You can take a look at this question for more information on autocrlf.

When using a .gitattributes file it's possible that a smudge filter will modify your files on checkout. Alternativly the text attribute can be used to enable autocrlf even if your .gitconfig disables it.

Possible solution

A possible solution in your case is to disable autocrlf globally (git config --global core.autocrlf false) and to remove the * text=auto line from your .gitattributes file.
You should proceed with commiting the .gitattributes file and pushing it to the remote.

As with every other commit you have to ensure for yourself that the changes are available on all branches you wish them to. They won't be magically available in the whole repository.

After that a clone should hopefully result in a clean working directory.

Final note

Usually git should ignore autocrlfed files to avoid cluttered status output like you are currently experiencing, but that doesn't seem to work always. Another reason to avoid autocrlf.

Community
  • 1
  • 1
Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73
  • I did as you said but I still get some modified files in my branch even if there are few than before now – ri5b6 Sep 09 '14 at 12:23
  • 2
    @ri5b6 what does git diff say ? Did you check what has been modified ? If its not line endings, you will know what – Mayur Nagekar Sep 09 '14 at 12:24
  • 1
    @ri5b6 `git config --global core.autocrlf` and `git config core.autocrlf` both print `false` and you removed the relevant line from the `.gitattributes` file? Keep in mind, it's important that you __commit and push__ the `.gitattributes` file afterwards before cloning again. – Sascha Wolf Sep 09 '14 at 12:25
  • I did the following: git config --global core.autocrlf=false, clone repository, remove the .gitattributes line, commit and push the .gitattributes file, clone repository again. Both commands print false now – ri5b6 Sep 09 '14 at 12:32
  • You have to remove the `.gitattribute` line, commit it, push it and then clone again. – Sascha Wolf Sep 09 '14 at 12:33
  • the git diff shows that the change is an additional ^M at the end of the line – ri5b6 Sep 09 '14 at 12:33
  • is it possible that I have to change the .gitattributes file in the branch that I am checking out as well? – ri5b6 Sep 09 '14 at 12:40
  • OK, now I have the solution! I removed the text=auto line also in the .gitattributes of the branch and now I could check out without modified files! @Zeeker, you could add this to your answer and then I will accept it – ri5b6 Sep 09 '14 at 12:46
  • @ri5b6 I think it's obvious that such a change won't automatically be available on every branch. It's the same as with every other change. Nethertheless I edited the answer. – Sascha Wolf Sep 09 '14 at 13:00
  • +1. [my suggestion in the comments](http://stackoverflow.com/questions/25742928/git-checkout-from-freshly-cloned-repository-into-a-branch-leads-to-unstaged-chan#comment40252693_25742928) was in the right direction, but you added all the necessary details. – VonC Sep 09 '14 at 13:19