"Out of the blue" I've started having this issue with a git repository that I have hosted on GitHub.
Whenever I pull a remote branch to my computer (even on the first clone of the repository) an arbitrary (?) set of files appear as "Changes not staged for commit". I am running on Windows 8.1 and using SourceTree alongside Git Bash as git clients.
An examination of the changes in these files shows that nothing has changed in them, except, maybe, the line endings. I don't know how to view the line endings when diffing so can't be sure.
When I try to "discard" these changes, it simply doesn't work. git reset --hard simply has no effect and the changes remain in place.
Why is this happening? How can I make it go away? :)
PS - When I run git config -l I see core.autocrlf=true appear 3 times in the list.
PPS - I have a .gitattributes file in the root of the repository. Deleting it does not have any effect on the above symptoms. It was first added a few days ago. It's all commented out except for * text=auto in the beginning of the file.
UPDATE:
I've found the minimum steps to reproduce my issue:
I open a file in a text-editor, add a single space somewhere and save it.
The file appears under "Changes not staged for commit" (obviously).
I remove the single space from the file and save it.
The file remains under "Changes not staged for commit" even though both SourceTree's diff and Kdiff3 show that the file is binary equal to its previous version.
Please note that the file in this example had CRLF line endings before I edited it and after I edited it - I don't understand why git insists on marking the file as changed.
UPDATE 2:
Running git diff --raw MyProject/app.config where MyProject.app/config is one of the files marked as changed gives:
:100644 100644 b960510... 0000000... M MyProject/app.config
The fact that the second SHA1 is all zeroes looks like a clue to me - but I don't know what it means.
This is a common problem when you set core.autocrlf after the fact. You can try this procedure from GitHub help. Another easy solution is to just clone a new local copy of the repository, which can also be a good troubleshooting step if you're still having problems.
UPDATE 3: I was able to resolve my issue by removing the .gitattributes file from the root of my repository.
The most likely suspect for having added this file into the repo in the first place is Visual Studio 2013 are per this Microsoft Connect issue.
I still don't understand why having this file (with this core.autocrlf=true in it) caused the behavior that I observed. If anyone has a good explanation, please post it as an answer and I will accept it.
Following the github article on dealing with line endings you can see that setting text=auto on the .gitattributes file tells git to "handle the files in whatever way it thinks is best." Seeing that the rest of the file was commented, and you had a star on text=auto, this was applied on everything. I suppose that in your case, what git thought was best, turned out to be the wrong choice.
Related
On my windows machine I'm considering setting autocrlf = true in my .gitconfig. Others on my team have it set this way and we've ended up with a mix of lf & crlf in the repo. I've considered a few options and this seems like the path of least resistance...
One thing I've noticed is that git checkout -p fails with the error patch does not apply when autocrlf = true. If I change it back to false it works as expected.
Is autcrlf = true incompatible with checkout --patch or is do I need to set some other option to get it to work?
Interestingly git add --patch works as expected with autocrlf = true.
Yes, git checkout --patch works properly with line ending translation. The patch almost certainly isn't applying because you have mismatched configuration.
Everybody on your team needs to use the same line ending configuration. core.autocrlf=true isn't an option that one person on a team can enable; everybody needs the same settings. That's because if you have core.autocrlf=false, then you're telling Git that the contents on disk are identical to the contents in the repository. If you're on Windows, that means that you're checking in files with Windows-style line endings (\r\n). If you have a colleague who enables core.autocrlf=true, then you're telling Git that the contents on disk have Windows-style line endings while the contents in the repository have Unix style line endings (\n).
But your colleague has told git a lie, since the repository contents actually have \r\n in them.
A variety of strange things can occur when these settings are mismatched, including things like patches failing to apply.
You should instead:
Set * text=auto in your .gitattributes file. This ensures that everybody working in the repository has the same settings, since the configuration is actually checked in and not something that everybody has to remember to configure properly.
Renormalize the repository, so that the repository contents actually match what you've claimed. You can do this by git add --renormalize . and checking the contents in.
Once you've done this (and everybody has updated your local working folders), your git apply --patch should behave correctly.
I have a very strange git error here that has me totally at a loss. It's not a major blocker, but it's extremely irritating to work around all the time.
I have a working copy of a repository and, in said working copy, every time I switch from one branch to another Git tells me, after the switch has completed, that I have local modifications. A few more details:
This is on Windows
Git status shows the file(s) as changed (every line as changed, see attached screenshot for an example)
Beyond compare shows no differences; file encoding and line endings are the same, both files exact same number of bytes.
The weird thing: I can't reset the changes, whatever they are. Even deleting the file and then resetting the deletion results in a new file that is supposedly changed.
What could be going on here? I thought that it might be something to do with file attributes, but I have no idea how to check this.
Update:
VonC was correct that it was line endings that were the issue. More specifically if you have core.autocrlf set to true but any files in the repository that were previously committed with Windows line endings then you will see this issue. The reason it's impossible to reset the change is the fact that checking out the file modifies it, since Git works out that your working copy of the file is different to how it would look if you were to commit it now. Confusing, I know.
Anyway, I was able to fix the issue by making one huge commit that set all the line endings in the repository to Unix, which luckily turned out not to be as huge a pain as you might think. I followed the instructions in this post: Trying to fix line-endings with git filter-branch, but having no luck, specifically the answer by Russ Egan, which worked best for me.
Simply make sure to type (once), before the next checkout:
git config --global core.autocrlf false
That will avoid the kind of automatic eol (end-of-line) transformation that this setting (set to true by default with msysgit) does.
.gitattributes files are a better place to declare the files you want to have their eol managed.
See "git replacing LF with CRLF" for more on that setting.
As I originally posted in this question...
I had some phantom changed files that were showing as modified, but were actually identical.
Running this command sometimes works:
(Turns off git's "smart" but often unhelpful line-ending conversions)
git config --global core.autocrlf false
git config --local core.autocrlf false
But in another case I found it was due to a .gitattributes file in the root which had some line-ending settings present, which was trying to apply autocrlf for certain files even when it was turned off. That wasn't actually helpful, so I deleted .gitattributes, committed, and the file no longer showed as modified.
I tried to do a search for my issue and the closest thing that I could is this.
git Status Shows Same File Twice - But with different path slash styles
But it doesn't seem to be the same issue I have.
I was doing a commit and noticed that the same file was listed twice but with different case. For instance, Directory/resource.h and Directory/Resource.h. Now there is only one file in the directory resource.h. If I look at the file through Git Extensions they look exactly the same. There doesn't seem to be another hidden file, there is only one file.
So I tried to fix this by removing the resource.h file, committing, and then adding the file back and recommit again. Only one file showed up as added. I thought I fixed the issue, but now if I try to checkout a different branch I get the following error.
error: The following untracked working tree files would be overwritten by checkout:
Directory/Resource.h
Please move or remove them before you can switch branches.
Aborting
Done
I don't really have any idea what to do from here, I've only been using Git for a few months and I haven't had to do anything more complicated than merging branches and pushing and pulling.
This can happen in Windows if you have a repo with ignorecase = false and rename a file without using git. To fix, this should work
git mv -f Resource.h resource.h
git commit -m 'fix case'
and this should prevent it from happening again.
git config core.ignorecase true
Git-svn allowed for a duplicate filename, just with different case, to be added to our subversion repository.
On Windows this meant that subversion could not checkout the file, complaining of a duplicate.
Another developer deleted the incorrectly cased version from the repository. Now when trying to do a git-svn rebase I get a "could not detach HEAD" message and a complaint about the file name in question being untracked and needing to be overwritten. Deleting the file makes git-svn complain that the file needs to be updated.
Is the only solution to copy the repository to a machine with a case sensitive filesystem do the rebase then move it back?
I understand that git-svn isn't ready for real world work on Windows but I'd like to recover from this mess it has created.
Best current answer (I don't know if this existed back when this was originally posed):
git config core.ignorecase true
Then redo the rebase. It will proceed without error -- and will even properly handle the case change in the filename.
This isn't specific to git-svn. It can happen in a straight 'git rebase'.
I hope that helps the next person....
I ran into a similar problem with Git (alone, not even with git-svn) getting very confused about changing the case of filenames when using a case-insensitive Mac filesystem. I didn't find a solution to fix the repository on the case-insensitive filesystem, but instead created a new case-sensitive volume in a .dmg file, mounted that, and used Git on that volume instead.
You may find that some of the Git "plumbing" commands might be helpful. For example, git checkout-index has a -f flag to force overwriting of existing files (also use -a with that command otherwise it might not do anything). The plumbing commands are generally more powerful (and more dangerous) than the porcelain commands, but may give you the flexibility you need to fix this.
The same way you always solve this problem under Windows. You have to rename one of the files, then you can restore the other one.
I'm having a hard time understanding some git/DCVS concepts. Here's what happened:
I created a git project, and imported it from an SVN repo
I made some commits
I wanted to experiment something, so I created a branch called constants-update
I switched to constants-updatebranch, moved some files, deleted others and added many more
I committed to this branch
Now I'm trying to switch to my master branch using git checkout master
I got this error: error: You have local changes to 'src/groovy/Constants.groovy'; cannot switch branches.
My understanding of DCVS is that I can switch branches at will, even if some branch has more or less files than the others, as long as I commit my files. I've tried committing with git commit -a and switching to master branch, but I have the same error.
As a side note, when I commit git warns me that LF will be replaced by CRLF and warns me about some trailing whitespaces also; after I commit I do a git status and a bunch of files always appear as #modified ....
Is this related to git/windows, or I do not understand correctly what it is supposed to happen? I just want to switch to my master branch without losing my changes in the other branch.
Lookup git-stash for changing branches while there are unsaved changes in the current branch.
You are correct in your thinking about how this should work.
However, it sounds like git is having issues with the line endings, and it thinks all your files are modified even when they aren't. I don't use git on Windows, but I was going to suggest the "core.autocrlf" option to make the crlf handling work. However, the following blog entry indicates that this might not be a good idea: http://weierophinney.net/matthew/archives/191-git-svn-Tip-dont-use-core.autocrlf.html
I solved the problem hacking my pre-commit hook (commenting these lines in .git/hooks/pre-commit with a #):
# if (/\s$/) {
# bad_line("trailing whitespace", $_);
# }
Just use the following option in .gitconfig file which resides in your users directory.
[core]
autocrlf = true
And it will solve the issue.