I installed Linux Mint on PC and then I cloned git repository from Bitbucket to work on it. After some changes I did commit in my PhpStorm ide. During this commit git fired me a dialog about line endings. There were two options. If I remember
create gitattribute file which handles line endings for project
set global handler for line endings via command like core.autocrlf true
I selected global option but as I see it made all the project files changed. Now I am not sure what happens and if I can push it to server. What happens if somebody pulls it on Windows? Will make a merge? How to solve it?
As per the git-config Documentation:
core.autocrlf
Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed.
Having core.autocrlf set to true means that git will conditionally convert line endings to CRLF in your working directory and to LF in your repository.
Please see: What's the best CRLF (carriage return, line feed) handling strategy with Git?
Related
My pc is a dual system with Linux Mint and Windows 11.
The git repo always has some changes in Linux.
Every time I need to git stash and git stash drop.
I don't know how to descript this situation with google.
Help pls. Thanks.
The problem is that you have different line ending settings between Linux and Windows. What you're seeing in Linux is that your files have carriage returns on the end of them, which is the Windows line ending.
The easiest way to solve this is to add this to .gitattributes:
* text=auto
Then, on an otherwise empty working tree, add that file, run git add --renormalize ., and commit. That will cause the files to be renormalized as having LF line endings in the index.
If you're going to be working across OSes, then you'd also do well to add eol=lf to the end of that line in .gitattributes so that files are always handled with LF endings. You'll also need to configure your tools on Windows to emit LF endings instead of CRLF endings. That will prevent line ending differences in the working tree across systems.
I'm going to answer my question with the fix what solved my problem.
Note for downvoters: I understand that the root cause is discussed in various other threads (that is how I solved my problem). This post is more about how having a dual boot system can lead you to this issue. So no, this question/answer is not a duplicate, but a particular instance of a general class of problems, adding more cases to SO's repository on this issue.
At home: I code in Linux. LF used as line ending
At the office: I code in windows. CRLF used as line endings.
By default, git's autocrlf feature (https://stackoverflow.com/a/20653073/2715083) keeps things happy.
However, if you run a dual boot system with Linux and Windows, you can mess yourself up in the following way:
git pull some files you worked on in a linux environment in a windows environment, in a location that can be accessed from the dual-booted linux environment. This modifies the files to contain CRLF endings.
Then when you open up the file in linux, where the default is only LF, git diff will say entire file is modified, because each LF got changed to CRLF at every single line. (I was warned by Atom, which has this diff count inbuilt)
you are talking about text=auto part? I wasn't sure If I need to include that in a new .gitattributes file or not, because when I did, ATOM still showed the files as modified.
Yes, it does.
To force Git to apply .gitattributes directives, see "Dealing with line endings".
I would first make sure core.autocrlf is set to false.
git config --global core.autocrlf false
Then:
git add . -u
git commit -m "Saving files before refreshing line endings"
rm .git/index
git reset
git status
git add -u
git add .gitattributes
git commit -m "Normalize all the line endings"
You can also use, to force the index re-normalization:
git rm --cached -r .
git reset --hard
See "Force LF eol in git repo and working copy"
* text=auto eol=lf
The FIX
Delete/move to another location the problem files/folders
do git checkout <hash> <your/files/location>
where <hash> is for the last good commit, and your/files/location being the location of the files you want to cure from the CRLF problem. This will basically restore the older versions from your local .git repository.
Worked for me.
If you know something i missed, or explained incorrectly, do let me know
I'm working on a project on Windows and some project files seems to be changed locally but I didn't. Was ignoring them but now I cannot push because are unstaged files. When I look into this files differences, there isn't, only this line ending thing (CRLF, LF).
Tried to revert this files, reset --hard too.
Why can't I reset this files to repository HEAD?
Tried to do this too:
git config --global core.autocrlf false
If I do git reset --hard and git status later I get message that have many files with changes not staged.
Sorry but I don't know git and this linux/windows line ending differences very well.
Maybe someone else working on the project introduced bad line endings. two things 2 do:
fix bad line endings already committed.
align the team about the line endings policy.
See: Dealing with line endings.
I've installed the latest version from git-scm.com on my Windows 8.1 System. My Dev Server is a Linux Server, but I'm connected to this server using a windows share.
After the git initalization, I've started to "add" files to the repositiory and received this message on the windows command line, for every file:
warning: LF will be replaced by CRLF in inc/src/tpl/default.smarty.
The file will have its original line endings in your working
directory.
While installing git I selected option 1 from this options:
Checkout Windows-style, commit Unix-style line endings
Checkout as-is, commit Unix-style line endings
Checkout as-is, commit as-is
So I'm working on windows, commiting over a windows share to a linux server, and I will also push these changes to another linux server.
Now I'm a little bit unsure about this setting because I'm working on a linux server. The only windows "Thing" is my command line and that I'm editing the files using a windows share.
I would like to know, if this is the right setting for git, or if I'm doing it wrong.
Thanks
I'm not 100% clear on your setup, but here is what is happening. The files you are adding have Unix-style line endings (i.e. they end with LF). Since you picked option 1, git is just warning you that when you check these files out on your Windows box, they will have Windows-style line endings (i.e. they will end with CRLF).
Normally this is nothing to worry about, but you mention that you "will also push these changes to another linux server." If by this you mean a git push, then no worries; the line endings will be normalized to Unix-style in the repository. However, if you mean that you copy the files from your Windows box to a Linux box, then you will eventually end up copying files with Windows-style line endings to the Linux box, which you probably don't want to do. If that is the case, you are probably better off with option 3. Note that if you edit these files on your Windows box, you may even want to go option 2, so that you will always have Unix-style line endings in the repository.
I am a bit confused with core.eol, core.autocrlf, core.safecrlf for git config.
http://git-scm.com/docs/git-config
I am using Ubuntu and Widows.
I had ^M, and other issues before.
Could anyone suggest the best git config setups for this problem?
Thanks in advance.
As detailled in Git on Windows (msysgit) - Unix or DOS line termination, I would use:
git config --system core.autocrlf false
That would avoid any automatic eol transformation (See "Git on Windows: What do the crlf settings mean?" for the exact meaning of this option value).
You can leave it to true, as explained in git replacing LF with CRLF, but I prefer setting core.eol + some gitattribute files in order to fine tune some of the files I want eol changes on.
See this answer for more details.