I am looking for a way to prevent TortoiseGit from flagging files as changed when they have Unix line endings. It is just tough to check if remote files have changed when you FTP download a folder, they show up as changed often because of the LF version that comes down. I'm on Windows, the repos are CRLF, but as I said when they change on the server they end up as LF.
Right click in that repository, TortoiseGit -> Settings
Turn local AutoCrlf OFF and apply the setting
Extra ref.
Read Dealing with line endings - Per-repository settings,
then try Dealing with line endings - Refreshing a repository after changing line endings
In my case all local files was showing change in newline chars. When I looked closely the 'CRLF' was converted to 'LF'. If I change the LF to CRLF manually, it was not working as in GIT repo it was showing it as difference in file.
I also tried Yue's changes but while clicking on Apply button it was asking me windows hook file, that I do not had.
Then i realized that recently I had installed "cygwin" on my system. I was done using that, so I removed it and restarted system, and all my problems gone.
My answer may help someone in my situation.
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.
"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.
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'm facing a strange situation with git . I just have edited several lines in a long file but then when I went to commit changes ,I saw that git just highlighted the whole file content with a red color . what is wrong ?
I'm using git's windows GUI
Edit : one thing I remember now is that I added .csproj to the gitignore list in last commit . does this has any effect on this ?
Update : the problem as friends suggested was from line ending . I solved it using this question's answer
The problem was because of line ending .
git config core.autocrlf was set to true . I used solutions mentioned in this 2 posts
Dealing with line endings
Trying to fix line-endings with git filter-branch, but having no luck
and set it as false . and it is solved.
We had the same problem in Visual Studio 2015 (vs2015) on Windows with files that we had edited but un-done all edits.
The only thing I would add to the other answer and what we ended up doing is to try editing the .gitattributes at the root of your solution by commenting out
* text=auto
to be
#* text=auto
According to this article, this entry overrides the git config so even if you remove the other entry in the git config the problem could still occur.
Commenting the .gitattributes removed the fake edits and uncommenting it added the fake edits back in for us.
Where this answer originally came from: Files showing as modified directly after git clone
I'm running a mixed environment, and keep a central, bare repository where I pull and push most of my stuff. This centralized repository runs on Linux, and I check out to Windows XP/7, Mac and Linux. In all repositories I put the following line in my .git/config:
[core]
autocrlf = true
I don't have the flag safecrlf=true anywhere. First time when I modify stuff on my one Windows machine (XP) there is no problem and when I look at the diff, it looks fine. But when I do the same on the other Windows machine (7), all lines are shown as changed but local line endings are \r\n as expected (when checked in a hex editor). The same applies to a MacOSX can. Sometimes I get the feeling that the different systems wrestle on line endings, but I can't be sure (I'm loosing track of all the times I change specific files).
I didn't use to have the autocrlf set, but set the flag many months back. Could that be causing my current problems? Do I need to clone everything again to loose some old baggage? Or are there other things that needs configuring too? I tried git checkout -- . about a million times, but with no success.
You need to set autocrlf to true on each machine you are working on (in global), or for each copy of the repository (in local). The settings of the repo you cloned from are not applied to your local repo.
The other answer is that you have a mixture of line endings in the files in your repo.
A filter on checkout could be setup for each of the source file type to correct their line endings, and on checkin to reset them to the repo standard.