Menu
Here is some pertinent output from the command line (with poshgit showing the status):
[Branch1]> git checkout Branch2
Switched to branch 'Branch2'
[Branch2 +0 ~3 -0]>
[Branch2 +0 ~3 -0]> git diff --ignore-space-at-eol
[Branch2 +0 ~3 -0]> git checkout .
[Branch2 +0 ~3 -0]>
I tried the solutions suggested in this question
[Branch2 +0 ~3 -0]> git reset --hard
HEAD is now at c8be749 some comment
[Branch2 +0 ~3 -0]> git reset HEAD
Unstaged another commit:
M Src/somefile
M Src/someotherfile.cs
M Src/athirdfile.cs
[Branch2 +0 ~3 -0]>
how does this happen and how can I fix it apart from committing the changes as I seem unable to undo the differences. Even stashing does nothing.
Some suggestions for how we got into this mess and how we can get out of it would be much appreciated.
I have been able to reproduce this reliably now so am in a position to get a more definitive answer. If I freshly clone me repo, then switch to a branch and then back to master I get some files which say they have changes. I have tried playing with the settings of core.autocrlf but that just seems to change the number of files that are affected and doesn't solve the problem completely.
What can I do to try and fix this increasingly annoying issue?
612
To switch to an existing branch, you can use git checkout again (without the -b flag) and pass the name of the branch you want to switch to: There is also a handy shortcut for returning to the previous branch you were on by passing - to git checkout instead of a branch name:
You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command.
There is a easy solution. If this happens (normally from unexpected windows shutdown or memory dump) and you cannot discard your changes and even switch between branches (Git says you don't have enough permission); in Windows environment show all hidden files and folders from folder options.
Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If this is not the case for the current setting of core.autocrlf, git will reject the file.
This problem could be due to line ending preferences in different operation system.
If you are Unix/Mac user then set you config as below
git config --global core.autocrlf input
git config --global core.safecrlf true
If you are on Windows then try config as below
git config --global core.autocrlf true
git config --global core.safecrlf true
After doing these setup, once you switch branches then git status should not complain about anything.
30
You didn't mention what OS you use, what OS your remote repo uses (if any) or whether your team works cross-platform with other OS's. That kind of info may help diagnose the problem.
I've seen problems like these crop up due to:
line-endings (Windows vs Mac vs Linux)
You fix this with core.*crlf settings and .gitattributes files. The github help page for this and the gitattributes manpage are the great resources for this.
Trying to fix line-endings with git filter-branch, but having no luck https://help.github.com/articles/dealing-with-line-endings https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
Don't miss the part at the end of the github help that talks about how you have to normalize your repo after getting this setup:
After you've set the core.autocrlf option and committed a .gitattributes file, you may find that git wants to commit files that you've not modified. This is because git wants to normalize the line endings for you. The best way to do this is ...
case-insensitive filesystems when files/dirs with mismatched case already exist
In particular, that Src dir looks particularly suspicious to me. This usually happens because someone renamed a file in the repo to the same name but used a different case for one or more letters. Then someone updates their local repo and work dir, git is told by the (case-insenstive filesystem) filesystem that the file/dir already exists, but other git code will treat the file/dir as new.
Try doing a fresh clone into an new or empty directory. See if the filename/dirname letter cases are different between the paths of the problematic files in your fresh clone and your original clone (look hard at the Src dir - it may be src in the repo. If available, I'd do the fresh clone on a Unix/Linux system.
Unicode characters in filenames
This doesn't seem to be the case for your problem, but I thought it worth mentioning for completeness. This is a variant of the case-insensitivity issue, but is also impacted by how a filesystem handles Unicode characters in filenames.
See Git clean not removing a file for a description of a problem someone else was having with Unicode in filenames.
71
git clean -id should do what you're looking for.
The i will let you verify what gets deleted while the d tells it to remove extra directories as well. Just be careful that it doesn't clean too much and take out anything you want to keep.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
