94

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

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

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

4

7 回答 7

119

对于使用 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

现在，您的工作树中的行尾将是正确的。

于 2013-03-26T20:30:33.647 回答
106

使用 Git 客户端 2.16 及更高版本，现在有一种更简单的方法来执行此操作。只需使用：

git add --renormalize .

注意：最好使用干净的工作空间来执行此操作。有关详细信息，请参阅：

于 2018-06-01T13:54:56.793 回答
11

替代方法（仅在使用的命令上有所不同）

确保您在存储库中没有任何待处理的更改：

$ 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
于 2017-08-07T12:11:40.210 回答
4

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

在新鲜克隆上小心使用。与任何可能有克隆人的人联系，并告诉他们你想做什么。

于 2013-03-26T19:42:48.137 回答
2

.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中的说明不能正常工作. 相反，这些步骤对我们有用：

情况：

  • 在 Windows 上
  • Git 存储库包含具有 CR 和 CRLF 行结尾的文件
  • 将 * text=auto 添加到 .gitattributes （因此不依赖于在 Windows 上设置 core.crlf=auto 的用户）

  • 还将 LFS 跟踪文件的 -crlf 更改为 -text，不确定是否需要。

    1. 从有行尾问题的分支创建一个新分支（假设那里没有未提交的更改）： git checkout -b feature/doing-stuff-fix-eol
    2. 从 .gitattributes 中删除 LFS 过滤器（将所有 'filter=lfs diff=lfs merge=lfs' 替换为空）
    3. 提交并推送： git commit -a -m "禁用 LFS 过滤器以进行 EOL 修复"
    4. 移动到非 git 文件夹
    5. 全局卸载 LFS：git lfs uninstall
    6. 创建一个新的存储库克隆： git clone -b feature/doing-stuff-fix-eol [远程存储库 url] fix-eol
    7. 规范化行尾： git add --renormalize 。（注意点以重新规范化所有文件）
    8. 仅检查规范化的正确文件。它不应该包括通常由 LFS 处理的文件！
    9. 提交并推送（保存哈希）： git commit -m "Fix line endings"
    10. 移动到非 git 文件夹
    11. 全局安装 LFS： git lfs install
    12. 转到原始存储库克隆并拉取
    13. 签出你原来的分支：git checkout feature/doing-stuff
    14. Cherry 选择 eol 修复提交并推送： git cherry-pick [hash]
    15. 删除eol分支并推送
    16. 删除 eol 存储库克隆（如果需要修复更多分支，请保留）
于 2019-06-28T11:02:23.870 回答
0

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

像这样：

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

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

于 2022-02-21T18:09:36.690 回答
0

merge.renormalize配置设置可能很有用。

于 2020-06-01T03:25:01.790 回答