试图修复线路

2018-06-20 08:24:07

我一直在用git来解决Windows / Linux的终结问题。看起来，通过GitHub，MSysGit和其他来源，最好的解决方案是让您的本地回购集使用linux风格的行结尾，但将core.autocrlf设置为true 。不幸的是，我没有做到这一点，所以现在每次我做出改变时，结局都是一团糟。

我以为我在这里找到了答案，但我无法让它为我工作。我的Linux命令行知识最多是有限的，所以我甚至不知道“xargs fromdos”行在他的脚本中的作用。我不断收到关于没有这样的文件或目录的消息，并且当我设法将其指向现有目录时，它告诉我我没有权限。

我已经在Windows上通过MSysGit和Mac OS X终端尝试了这一点。

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之前取消其文本属性。

manual.pdf -text

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

weirdchars.txt text

这利用了git v2.16.0中新添加的--renormalize标志，2018年1月发布。对于旧版本的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会将许多文件标记为已修改。

解决办法是做一个假提交（ git add -A . && git commit -m 'fake commit' ）然后git rebase master 。重新绑定后，虚假提交应该消失。

链接地址: http://www.djcxy.com/p/57233.html

上一篇: Trying to fix line

下一篇: How do I remove files saying "old mode 100755 new mode 100644" from unstaged changes in Git?

试图修复线路

.gitattributes内容

正常化后的问题

`.gitattributes`内容