在Windows下,我希望使用LF行结尾检查所有的Linux shell文件(.sh)。其他基于文本的文件的行结尾应该转换为CRLF(这通过全局core.autocrlf=true处理)。
全局.gitconfig ``` [core] editor = 'C:/Tools/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin autocrlf = true ```
存储库根目录中的.gitattributes ``` *.sh text eol=lf ```
当添加.gitattributes文件时,我使用了"git add --renormalize ."命令。不幸的是,在检出后.sh文件仍然具有CRLF。
附加信息:我的一个团队成员几个提交之前更改了他的全局core.autocrlf=false,这导致了混乱的行结尾。
尝试的步骤: - 本地删除文件并重新检出: 没有影响 - 全部为CRLF. - 删除文件,推送删除操作,使用LF重新创建文件: 检出后仍然为CRLF。 - 使用Notepad++手动更改行结尾...
全局.gitconfig ``` [core] editor = 'C:/Tools/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin autocrlf = true ```
存储库根目录中的.gitattributes ``` *.sh text eol=lf ```
当添加.gitattributes文件时,我使用了"git add --renormalize ."命令。不幸的是,在检出后.sh文件仍然具有CRLF。
附加信息:我的一个团队成员几个提交之前更改了他的全局core.autocrlf=false,这导致了混乱的行结尾。
尝试的步骤: - 本地删除文件并重新检出: 没有影响 - 全部为CRLF. - 删除文件,推送删除操作,使用LF重新创建文件: 检出后仍然为CRLF。 - 使用Notepad++手动更改行结尾...
*.sh
文件,然后再次检出。 - sschuberth*.sh
文件副本,这些副本在文件的提交版本中具有 CRLF 行尾。 (通常情况下,使用core.autocrlf = true
,不会发生这种情况,但有各种方法可以使其发生,在此之后,文件将保持原样,直到您更改它们。)如果是这种情况,则要做的事情是手动修复文件一次,例如使用dos2unix
,添加并提交。 - torek.gitattributes
条目将处理所有 新 提交的事务。但请注意:如果这个猜测是错误的,那么在使用dos2unix
或等效工具和git add
之后,Git 将会说没有需要提交的内容。 - torek