这个换行符问题让我头疼不已...
背景:历史上,我使用了core.autocrlf设置,但我发现不同的代码库表现不佳(我在Windows上工作,有些代码库需要LF结尾,有些则需要CRLF结尾)。因此,我试图摆脱这种设置,在每个代码库中使用.gitattributes文件(我希望Git保持沉默,让我管理换行符!)。所以现在我把core.autocrlf设置为false,并为我正在处理的Visual Studio项目创建了一个.gitattributes文件,内容如下:
我使用unix2dos强制将repo中的所有文件转换为CRLF结尾,并确认它们在工作目录中具有正确的行结尾,并将其全部检入。是的,我遵循了这里的建议Trying to fix line-endings with git filter-branch, but having no luck 这几乎是完美的。
问题在于,每当我更改一个文件时,git会报告更改的行存在行结尾差异,例如,如果原始行是:
似乎Git认为仓库中的文件仍然具有LF结尾(因为它们在过去被标准化了?)。^M会导致大量视觉噪音,我不确定这是否是其他任何症状。我不明白为什么Git会报告差异,因为我已经在之前的提交中检查了所有带有CRLF结尾的文件,事实上,就在这个提交之前。
那么我为什么要得到这些“虚假”的差异,如何摆脱它们?
背景:历史上,我使用了core.autocrlf设置,但我发现不同的代码库表现不佳(我在Windows上工作,有些代码库需要LF结尾,有些则需要CRLF结尾)。因此,我试图摆脱这种设置,在每个代码库中使用.gitattributes文件(我希望Git保持沉默,让我管理换行符!)。所以现在我把core.autocrlf设置为false,并为我正在处理的Visual Studio项目创建了一个.gitattributes文件,内容如下:
# Don't do any end of line normalization.
* -text
# Always treat these files as binary. Not strictly necessary, but can't hurt.
*.png binary
*.gif binary
*.jpg binary
*.jpeg binary
*.dll binary
*.doc binary
*.docx binary
*.xls binary
*.xlsx binary
*.pdf binary
我使用unix2dos强制将repo中的所有文件转换为CRLF结尾,并确认它们在工作目录中具有正确的行结尾,并将其全部检入。是的,我遵循了这里的建议Trying to fix line-endings with git filter-branch, but having no luck 这几乎是完美的。
问题在于,每当我更改一个文件时,git会报告更改的行存在行结尾差异,例如,如果原始行是:
string s;
修改后的行为:
string sucks;
git diff 展示的是变更内容:
string sucks;^M
似乎Git认为仓库中的文件仍然具有LF结尾(因为它们在过去被标准化了?)。^M会导致大量视觉噪音,我不确定这是否是其他任何症状。我不明白为什么Git会报告差异,因为我已经在之前的提交中检查了所有带有CRLF结尾的文件,事实上,就在这个提交之前。
那么我为什么要得到这些“虚假”的差异,如何摆脱它们?