尝试使用git filter-branch修复行结尾,但没有运气

Question

我被git用Windows/Linux行结束问题所困扰.看来,通过GitHub,MSysGit和其他来源,最好的解决方案是让你的本地存储库设置为使用linux风格的行结尾,但设置core.autocrlf为true.不幸的是,我没有及早做到这一点,所以现在每次我进行更改时,行结尾都会被剔除.

我以为我在这里找到了答案,但我无法让它为我工作.我的Linux命令行知识充其量是有限的,所以我甚至不确定"xargs fromdos"行在他的脚本中做了什么.我不断收到关于没有这样的文件或目录的消息,当我设法将它指向现有目录时,它告诉我我没有权限.

我在Windows上通过Mac OS X终端尝试使用MSysGit.

Answer 1

解决此问题的最简单方法是进行一次修复所有行结尾的提交.假设您没有任何已修改的文件,则可以按如下方式执行此操作.

# 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 .

Answer 2

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 status,请在运行git add -u之前取消设置其text属性.

manual.pdf -text

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

weirdchars.txt text

这利用了--renormalize在2018年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"

Answer 3

我处理行结尾的程序如下(在许多回购中进行了战斗测试):

创建新的仓库时:

• 摆.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.在rebase之后,假提交应该消失.