如何在Git中规范化工作的树行结尾

我克隆了一个行结尾不一致的存储库。我添加了一个.gitattributes，它为我想要规范化的文件设置文本属性。现在，当我提交更改时，我得到消息:

warning: CRLF will be replaced by LF in FILE.
The file will have its original line endings in your working directory.

我如何让git为我规范我的工作文件副本?最好我想git标准化整个工作树。

对于使用v2.16或更高版本的用户，您可以简单地使用:

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"

这些方向直接来自gitattributes。对于旧版本，文档(v2.12之前)提供了一个不同的答案:

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"

在编辑完.gitattributes后执行此顺序。

更新

似乎有些用户在使用上述说明时遇到了麻烦。gitattributes的更新文档(2.12到2.14)显示了一组新的指令(在编辑。gitattributes文件之后):

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"

感谢@vossad01指出这一点。

同样，无论使用哪种解决方案，工作副本中的文件仍然保留其旧的行结尾。如果你想更新它们，确保你的工作树是干净的，并使用:

git rm --cached -r .
git reset --hard

现在行结束在你的工作树将是正确的。

对于Git客户端2.16及更高版本，现在有一种更简单的方法来完成此操作。只使用:

git add --renormalize .

注意:最好在一个干净的工作环境中这样做。详情请参见:

https://git-scm.com/docs/gitattributes _end_of_line_conversion
https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings refreshing-a-repository-after-changing-line-endings

另一种方法(仅在使用的命令不同)

确保存储库中没有任何挂起的更改:

$ git status
$ git stash

修改.gitattributes使CRLF解释改变:

$ echo "*.txt  text" >>.gitattributes
$ git commit -m "Made .txt files a subject to CRLF normalization." -- .gitattributes

从索引中删除数据并刷新工作目录:

$ git rm --cached -r .
$ git reset --hard

查看Git建议的CRLF修复:

$ git ls-files --eol
$ git status
$ git diff

同意Git的决定:

$ git add -u
$ git commit -m "Normalized CRLF for .txt files"

重新加载更改，就像完成了干净克隆一样:

$ git rm --cached -r .
$ git reset --hard

.gitattributes设置只会影响新提交。如果这个存储库没有发布历史记录(没有其他依赖于它的历史记录)，您可能想要浏览整个历史记录。在Unix/Linux中，您可以使用dos2unix(1)与find(1)一起修复所有文件，并且使用filter-branch的历史重写(参见git书中的讨论)，您甚至可以清理项目的全部历史。

在一个新克隆体上使用时要格外小心。与任何可能有克隆的人联系，并建议他们你想做什么。

.gitattributes中的* text=auto选项使Git存储库处于'非法状态'，如果它包含CRLF (Windows)行结尾的文件，现在被标记为文本(参见https://marc.info/?l=git&m=154484903528621&w=2)。标准的renormalize选项不能正确地与LFS过滤器一起工作，因此其他答案中的说明或例如https://help.github.com/en/articles/dealing-with-line-endings中的说明不能正确工作。相反，这些步骤对我们有效:

Git存储库包含以CR和CRLF行结尾的文件
添加* text=auto到。gitattributes(所以不依赖于用户设置核心)。crlf=auto (Windows)
还将LFS跟踪文件的-crlf更改为-text，不确定是否需要。
1. 从有行结束问题的分支创建一个新的分支(假设那里没有未提交的更改):git checkout -b feature/doing- thing -fix-eol
2. 从.gitattributes中删除LFS过滤器(将所有'filter= LFS diff= LFS merge= LFS '替换为none)
3. 提交和推送:git Commit -a -m "Disable LFS filters for EOL fix"
4. 移动到非git文件夹
5. 全局卸载LFS: git LFS Uninstall
规范行尾:git add——renormalize。(注意点表示重新规范化所有文件)
只检查规范化的正确文件。它不应该包括通常由LFS处理的文件!
提交和推送(保存散列):git Commit -m "Fix line ending "
移动到非git文件夹
转到原始存储库克隆并拉出
签出原始分支:git Checkout feature/doing-stuff
删除eol分支并推送
删除eol库克隆(或保留，如果你需要修复更多的分支)

我不得不用这个标志-c core.autocrlf=false重新克隆repo，它工作了，不需要其他配置。

git clone -c core.autocrlf=false https://github.com/any-repo.git

我们的项目最初是用Mac上的LF制作的，但在Windows上它会自动转换为CRLF。我们使用eslint，它在每一行代码下划了线，直到我重新克隆它。

我在工作树中有CRLF行结尾，在存储库中有LF，因为项目文件夹刚刚从Windows机器复制到Linux机器，使用Git 1.8.3。这就是我如何将行尾重置为LF:

git status返回所有更改文件的列表
git diff忽略行尾并返回"really"改变了
comm -3比较列表并返回git status列表中不在git diff列表中的文件
git checkout将这些文件重置为HEAD

comm -3 <(git status --porcelain --untracked-files=no | cut -c4- | sort) <(git diff --name-only | sort) | xargs git checkout HEAD --

merge.renormalize配置设置可能有用

另一种方法(仅在使用的命令不同)

相关内容

最新更新

热门标签：