CODEWITHSUNDEEP
gitbranchgit-branch
Simon Gillbee
Simon Gillbee

Reputation: 3982

Why changing branches results in uncommited changes?

I've got a really odd situation... it may be because I'm relatively new to git, but this seems wrong. Every time I change branches from the command line, I get a set of uncommitted changes (different depending which branch I checkout).

I'm working with a Stash repository ("Stash" the Git repository, like a private GitHub, not "git stash" the command). This repo has multiple branches: master / development / feature1, etc.

To be clear, I've made NO changes to any branches... I'm a brand-new user connecting on a brand new client, freshly installed. I'm just browsing the branches and making sure that each branch builds on my system.

Here are the commands I used:

git branch -a

This lists all the branches and initially showed I have "master" locally and other branches remote.

I then checked-out the development branch

git checkout -b development origin/development
git status

This shows me that I now have about 20 uncommitted changes, including some source files, project files and a few misc data files. Why? Is this normal git behavior?

I try to go back to master:

git checkout master

But this fails due to uncommitted changes. If I force it:

git checkout master -f

it seems to work fine and I'm back on the master branch with no uncommitted changes.

Really?!? The uncommitted changes are not even the diffs between the branch... only a subset. What can explain this behavior? And how can I stop it?

FYI, running git version 1.8.3.msysgit.0 on Windows 7

Upvotes: 1

Views: 92

Answers (1)

Thomas Kelley
Thomas Kelley

Reputation: 10292

I'm almost 100% sure this is related to the classic problem of Windows vs. Linux/Mac line endings -- i.e., the fact that when you hit the "Enter" key in Windows, you get a different character/set of characters than when you hit "Enter" in Linux or Mac. (If you're curious, here's some information on that problem)

To know for sure if this is your problem, run a git diff. If the result shows that the lines taken away had the same content (or "look the same") as the lines added, then it's likely a whitespace issue.

Git knows about this problem, and will manage the line endings for you...if you tell it to. Try changing your autocrlf option:

git config --global core.autocrlf true

And see if the problem persists.

You may still need to re-normalize the repository for these differences. If so, GitHub has a great article on this. See the bottom section for details on re-normalizing.

(Oh, and in case I'm way off here, then update your question with examples of what you found in git diff, and we can use that to figure this out.)

Upvotes: 1

Related Questions