Git checkout from freshly cloned repository into a branch leads to unstaged changes in that branch

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

Sascha Wolf

There are multiple reasons this could happen.

You have the core.autocrlf setting enabled
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.

来源：https://stackoverflow.com/questions/25742928/git-checkout-from-freshly-cloned-repository-into-a-branch-leads-to-unstaged-chan

标签

git

gitblit