I have cloned a repository that had inconsistend line endings. I have added a .gitattributes that sets the text attribute for the files I want to normalize. Now when I commit changes I get the message:
warning: CRLF will be replaced by LF in FILE.
The file will have its original line endings in your working directory.
How can I make git normalize my working copy of the file for me? Preferably I would like git to normalize the entire working tree.
With Git client 2.16 and higher there is now a much simpler way to do this. Just use:
git add --renormalize .
Note: it's better to do this with a clean workspace. For details, see:
error: unknown option 'renormalize' –
Portrait git --version say? I would guess it's simply older than 2.16 and you need to upgrade. HTH –
Dihedron git status returns something like nothing to commit, working tree clean –
Dihedron For those using v2.16 or better, you can simply use:
git add --renormalize . # Update index with renormalized files
git status # Show the files that will be normalized
git commit -m "Introduce end-of-line normalization"
These directions are straight out of the gitattributes. For older versions, the docs (prior to v2.12) provide a different answer:
rm .git/index # Remove the index to force git to
git reset # re-scan the working directory
git status # Show files that will be normalized
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"
Do this sequence after you have edited .gitattributes.
It appears some users have had trouble with the above instructions. Updated docs for gitattributes (2.12 to 2.14) shows a new set of instructions (after editing the .gitattributes files):
git read-tree --empty # Clean index, force re-scan of working directory
git add .
git status # Show files that will be normalized
git commit -m "Introduce end-of-line normalization"
Thanks to @vossad01 for pointing this out.
Also, with either solution the files in your working copy still retain their old line endings. If you want to update them, make sure your working tree is clean and use:
git rm --cached -r .
git reset --hard
Now the line endings will be correct in your working tree.
.gitattributes for the first time or changing the setting, but it doesn't work if the working tree has a different EOL (at least with MsysGit it doesn't). For that, it appears that git rm --cached -r . and then git reset --hard worked (warning: destroys your working tree). From help.github.com/articles/dealing-with-line-endings. –
Clementeclementi git add . after removing the index (being mindful of anything in the working directory that was previously untracked). –
Limitation git add -u to work is that the file must have been versioned already (it must be part of the repo). So maybe that where things fail? I tried this with 2.15.0, so it's possible there was some other bug affecting this for some short time too. –
Carlcarla git read-tree --empty; git add . variant. Any tracked files that would be ignored by .gitignore will be deleted when using it. The documentation now recommends git add --renormalize . –
Limitation git config --get core.autocrlf say? –
Carlcarla false. But even when it "tries" to convert line endings it too quick, like 5 seconds for 1000 files. In the end I used notepad++ to do a global search and replace. –
Wring .gitattributes set up? I've never seen this be a real problem, even under Windows. It sounds like you've missed a step or there is something environmental going on. And 5 seconds for 1,000 is quite possible. The conversion is pretty darn easy, and Git is awfully efficient in what it does. Sorry it was an issue for you though. –
Carlcarla With Git client 2.16 and higher there is now a much simpler way to do this. Just use:
git add --renormalize .
Note: it's better to do this with a clean workspace. For details, see:
error: unknown option 'renormalize' –
Portrait git --version say? I would guess it's simply older than 2.16 and you need to upgrade. HTH –
Dihedron git status returns something like nothing to commit, working tree clean –
Dihedron Make sure you have no any pending changes in repository:
$ git status
$ git stash
Modify .gitattributes so CRLF interpretation will changed:
$ echo "*.txt text" >>.gitattributes
$ git commit -m "Made .txt files a subject to CRLF normalization." -- .gitattributes
Remove data from index and refresh working directory:
$ git rm --cached -r .
$ git reset --hard
Review CRLF fixes that Git proposes:
$ git ls-files --eol
$ git status
$ git diff
Agree with Git decision:
$ git add -u
$ git commit -m "Normalized CRLF for .txt files"
Reload changes as if clean clone was done:
$ git rm --cached -r .
$ git reset --hard
--eol option to git ls-files is new in Git 2.8 (not that new any more, but some people are still suffering with Git 1.7, even late in 2018!). –
Magnanimity git ls-files --eol helps verify that your line endings in all files are as intended, thanks! –
Eidetic The .gitattributes settings will only affect new commits. If this repository has no history published (no others depending on it), you might want to go through the whole history. In Unix/Linux, you can use dos2unix(1) to fix all files in combination with find(1), and using the history rewriting of filter-branch (see the discussion in the git book) you can even clean up the full history of the project.
Use with utmost care, on a fresh clone. Get in contact with anybody who might have a clone, and advise them what you want to do.
I had to re-clone repo with this flag -c core.autocrlf=false, and it worked, no other config required.
Like this:
git clone -c core.autocrlf=false https://github.com/any-repo.git
Our project initially was made with LF on Mac, but on Windows it was automatically converted to CRLF. We use eslint and it underlined every line of code, until I re-cloned it.
The * text=auto option in .gitattributes leaves the Git repository in an 'illegal state' if it contains files with CRLF (Windows) line endings which are now marked as text (see https://marc.info/?l=git&m=154484903528621&w=2). The standard renormalize option does not work correctly with the LFS filters, so the instructions in the other answers or for example at https://help.github.com/en/articles/dealing-with-line-endings, do not work correctly. Instead these steps worked for us:
Situation:
Also changed the -crlf to -text for LFS tracked files, not sure that is needed.
I've had CRLF line endings in working tree and LF in repository, because project folder was just copied from a Windows machine to a Linux one with Git 1.8.3. This is how I've reset line endings to LF:
git status returns a list of all changed filesgit diff ignores line endings and returns files which are "really" changedcomm -3 compares lists and returns files from git status list which are not in git diff listgit checkout resets these files to HEADcomm -3 <(git status --porcelain --untracked-files=no | cut -c4- | sort) <(git diff --name-only | sort) | xargs git checkout HEAD --
The merge.renormalize configuration setting may be useful.
© 2022 - 2024 — McMap. All rights reserved.