试图用git filter-branch修复行尾，但是没有运气

我一直被git的Windows / Linux行尾问题所困扰。似乎通过GitHub，MSysGit和其他来源，最好的解决方案是将本地存储库设置为使用linux样式的行尾，但设置core.autocrlf为true。不幸的是，我还没有做得足够早，所以现在每次我进行更改时，行尾都令人讨厌。

我以为我在这里找到了答案，但我无法为我工作。我的Linux命令行知识充其量是有限的，因此我什至不确定“ xargs fromdos”行在其脚本中的作用。我不断收到有关不存在此类文件或目录的消息，当我设法将其指向现有目录时，它告诉我我没有权限。

我已经在Windows上通过Mac OS X终端在MSysGit上进行了尝试。

gitattributes的git文档现在介绍了另一种“修复”或规范化项目中所有行尾的方法。这是要点：

$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status        # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"

如果任何不应该标准化的文件都显示为git状态，请在运行git add -u之前取消设置其text属性。

manual.pdf -text

相反，git未检测到的文本文件可以手动启用规范化。

weirdchars.txt text

这利用了--renormalize2018年1月发布的git v2.16.0中添加的新标志。对于较旧版本的git，还有更多步骤：

$ echo "* text=auto" >>.gitattributes
$ 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"

解决此问题的最简单方法是进行一次提交，以修复所有行尾。假设您没有任何修改的文件，则可以按以下步骤进行操作。

# From the root of your repository remove everything from the index
git rm --cached -r .

# Change the autocrlf setting of the repository (you may want 
#  to use true on windows):
git config core.autocrlf input

# Re-add all the deleted files to the index
# (You should get lots of messages like:
#   warning: CRLF will be replaced by LF in <file>.)
git diff --cached --name-only -z | xargs -0 git add

# Commit
git commit -m "Fixed crlf issue"

# If you're doing this on a Unix/Mac OSX clone then optionally remove
# the working tree and re-check everything out with the correct line endings.
git ls-files -z | xargs -0 rm
git checkout .

我处理行尾的过程如下（在许多存储库上经过了实战测试）：

创建新的仓库时：

• 摆.gitattributes在首先与其他典型的文件，提交沿 .gitignore和README.md

处理现有回购协议时：

• 创建/修改.gitattributes相应
• git commit -a -m "Modified gitattributes"
• git rm --cached -r . && git reset --hard && git commit -a -m 'Normalize CRLF' -n"
  • -n（--no-verify是跳过预提交的挂钩）
  • 我必须经常做，以至于我将其定义为别名 alias fixCRLF="..."
• 重复上一个命令
  • 是的，这是伏都教，但通常我必须运行两次命令，第一次是对某些文件进行规范化，第二次是对更多文件进行规范化。通常，最好重复直到没有新的提交创建为止：）
• 在旧分支（刚好归一化）和新分支之间来回几次。切换分支后，有时git会发现更多需要重新规范化的文件！

在此，.gitattributes我将所有文本文件明确声明为具有LF EOL因为通常Windows工具与LF兼容，而非Windows工具与CRLF不兼容（即使许多nodejs命令行工具都假定LF，因此可以更改文件中的EOL）。

内容 .gitattributes

我.gitattributes通常看起来像：

*.html eol=lf
*.js   eol=lf
*.json eol=lf
*.less eol=lf
*.md   eol=lf
*.svg  eol=lf
*.xml  eol=lf

要弄清楚git在当前仓库中跟踪了哪些不同的扩展，请看这里

归一化后的问题

一旦完成，还有另外一个常见警告。

假设您master已经更新并进行了标准化，然后结帐outdated-branch。通常在签出该分支后，git会将许多文件标记为已修改。

解决的方法是先进行伪commit（git add -A . && git commit -m 'fake commit'），然后执行git rebase master。重新设置基准之后，伪造的提交将消失。

git status --short|grep "^ *M"|awk '{print $2}'|xargs fromdos

说明：

• git status --short

  这将显示git知道和不知道的每一行。不受git控制的文件在行的开头标记有“？”。被修改的文件标有M。

• grep "^ *M"

  这只会过滤掉那些已被修改的文件。

• awk '{print $2}'

  这仅显示文件名，没有任何标记。

• xargs fromdos

  这将从上一个命令中获取文件名，并通过实用程序“ fromdos”运行它们以转换行尾。

这是我使用固定整个历史记录中所有行尾的方式git filter-branch。该^M字符需要使用输入CTRL-V+ CTRL-M。我曾经dos2unix转换过文件，因为这会自动跳过二进制文件。

$ git filter-branch --tree-filter 'grep -IUrl "^M" | xargs -I {} dos2unix "{}"'

“ | xargs fromdos”从标准输入中读取（文件会find找到），并将其用作命令的参数，该命令fromdos将转换行尾。（在那些环境中fromdos是标准的吗？我习惯于dos2unix）。请注意，您可以避免使用xargs（如果您有足够的文件以至于参数列表对于xargs来说太长，则特别有用）：

find <path, tests...> -exec fromdos '{}' \;

要么

find <path, tests...> | while read file; do fromdos $file; done

我不太确定您的错误消息。我成功测试了这种方法。每个产生什么程序？您没有权限访问哪些文件/目录？但是，这是猜测您可能是什么样的刺痛方法：

一种获取脚本“找不到文件”错误的简单方法是使用相对路径-使用绝对路径。同样，如果您没有使脚本可执行（chmod + x），则可能会出现权限错误。

添加评论，我将尽力帮助您解决问题！

好的...在cygwin下，我们没有易于使用的fromdos，如果您在修改文件的路径（我们拥有的空间）中留有空格，那么awk substeb会在您的脸上炸开，所以我不得不做些不同的事情：

git status --short | grep "^ *M" | sed 's/^ *M//' | xargs -n 1 dos2unix

对于此解决方案的大部分，@ lloyd表示感谢

如果没有其他答案适合您，请按照下列步骤操作：

1. 如果您使用的是Windows，请执行git config --global core.autocrlf true; 如果您使用的是Unix，请执行git config core.autocrlf input
2. 跑 git rm --cached -r .
3. 删除档案 .gitattributes
4. 跑 git add -A
5. 跑 git reset --hard

那么您的本地人应该现在就干净了。