我尝试使用CRLF结束行提交文件,但失败了。
我花了整整一天的时间在我的Windows计算机上尝试不同的策略,几乎被迫停止尝试使用Git而是尝试使用Mercurial。
每个答案只能分享一个最佳实践。
在提出这个问题差不多四年后,我终于来了
找到了一个完全满足我的答案!
请参阅github中的详细信息:帮助指南
处理行结尾。
Git allows you to set the line ending properties for a
repo directly using the text attribute in the
.gitattributes file. This file is committed into
the repo and overrides the core.autocrlf setting,
allowing you to ensure consistent behaviour for all
users regardless of their git settings.
因此
The advantage of this is that your end of line
configuration now travels with your repository and you
don't need to worry about whether or not collaborators
have the proper global settings.
这是.gitattributes文件的示例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
| # Auto detect text files and perform LF normalization
* text=auto
*.cs text diff=csharp
*.java text diff=java
*.html text diff=html
*.css text
*.js text
*.sql text
*.csproj text merge=union
*.sln text merge=union eol=crlf
*.docx diff=astextplain
*.DOCX diff=astextplain
# absolute paths are ok, as are globs
/**/postinst* text eol=lf
# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf |
对于最流行的编程语言,有一个方便的即用型.gitattributes文件集合。让你入门是有用的。
一旦创建或调整了.gitattributes,就应该执行一次又一次的所有行结束重新规范化。
请注意,在应用程序中打开项目的Git仓库后,GitHub桌面应用程序可以建议并创建.gitattributes文件。要尝试此操作,请单击齿轮图标(位于右上角)>存储库设置...>行结尾和属性。系统将要求您添加推荐的.gitattributes,如果您同意,该应用程序还将对存储库中的所有文件执行规范化。
最后,记住你的线路结束文章
提供了更多背景知识,并解释了Git如何发展
关于手头的事情。我认为这需要阅读。
您的团队中可能有用户使用EGit或JGit(Eclipse和TeamCity等工具使用它们)来提交更改。然后你运气不好,正如@gatinueta在这个答案的评论中解释的那样:
This setting will not satisfy you completely if you have people working with Egit or JGit in your team, since those tools will just ignore .gitattributes and happily check in CRLF files https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
一个技巧可能是让他们在另一个客户端提交他们的更改,比如SourceTree。然后我们的团队更喜欢Eclipse的EGit工具,用于许多用例。
谁说软件很简单? : - /
-
小心分享Windows .gitattributes?
-
你如何看待GitHub for Windows为你的项目所做的.gitattributes是什么?我安装了GitHub for Windows,启动了GUI版本,但无法找到与.gitattributes建议相关的任何选项。
-
@JLDiaz,为Windows启动GitHub,并在存储库列表中打开您选择的一个。一旦(并且只有一次)打开存储库,单击工具菜单,选择设置,您应该在右侧看到我的意思。
-
@BrechtMachiels如果你做* text=auto !eol,你还需要在你的git配置中设置autocrlf吗?
-
@BrechtMachiels .gitattributes接管包含.gitattributes的repo的autocrlf配置。因此,有些人可能希望在一般情况下为他们使用的没有.gitattributes的repos设置autocrlf。但我可能已经掩饰了你的!eol部分;我不记得它做了什么。
-
如果您的团队中有人与Egit合作,此设置将无法完全满足您,因为egit将忽略.gitattributes并愉快地签入CRLF文件bugs.eclipse.org/bugs/show_bug.cgi?id=342372
-
对于Windows,我通常倾向于设置全局core.autocrlf = false - 我更喜欢LF无处不在,但是像Visual Studio这样的一些Windows工具坚持在某些文件中使用CRLF结尾(甚至将它们混合在一起......);不是线路结尾是最安全的选择。如果您知道自己在做什么,我可能会使用core.autocrlf = input并为Windows上您知道对行结尾敏感的项目设置例外。正如其他人所指出的,现在每个体面的文本编辑器都支持LF结尾。我实际上认为core.autocrlf = true可能会导致比它阻止更多的麻烦。
-
我认为* text=auto仅适用于根目录中的文件[或者更确切地说,是.gitattributes文件目录的位置],是吗?
-
@gatinueta更具体地说,这是一个JGit问题。意思是TeamCity,也使用JGit,直接忽略.gitattributes。
-
可以在github.com/Danimoth/gitattributes上找到最流行的编程语言的即用型.gitattributes文件的集合。
-
"记住你的终结线"的链接被打破了。这是同一篇文章吗? adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line
-
在团队资源管理器(非团队城市)中使用git的Visual Studio似乎确实支持.gitattributes:blogs.msdn.com/b/visualstudioalm/archive/2013/02/26/…
-
我还建议使用*.sh text eol=lf
-
@DanielJomphe如果团队成员使用不同的平台怎么办?共享.gitattributes文件如何在Windows上为某人工作,在Linux上为另一人工作?
-
@DanielJomphe:我还要补充一点:set core.safecrlf = true。通过在提交时立即抗议来防止悲伤,而不是以后
不要转换行结尾。解释数据并不是VCS的工作 - 只需存储和版本化即可。无论如何,每个现代文本编辑器都可以读取两种行结尾。
-
借调。如果您遇到不一致的行结尾问题,那么最好的解决方案就是对使用错误编辑器设置的人大喊大叫,直到他们修复它为止。
-
我对这个策略感到满意,但是 - 我做错了什么? - 如果我没有使用dos2unix手动转换文件,或者如果我没有使用autocrlf配置它,git会拒绝我的提交。像"补丁包含可疑线"之类的东西,还有一些时候,"在eol上可疑的空白"
-
Daniel:我不使用Git,但这可能是repo中的配置选项。
-
不同意。所有平台上的原生换行都很方便。
-
除了CRLF之外,Visual Studio还是一个PITA。
-
Git有一个不转换行结尾的选项,它是autocrlf = false,除非你正在进行跨平台开发,比如Mono,最好在Windows下运行时保持为假,如果要开发开源,则设置为true对于单声道。
-
如果不解释要使用哪些设置来避免转换行结尾,这个答案就不是很有用了。
-
行结尾的问题是计算正确的差异。所以答案是错误的和误导性的。
-
如果你在Windows上工作,你真的没有太多选择。您需要在Windows上使用CRLF模式的文件,而在Unix-ish平台上只需要LF。
-
绝大多数使用sftp for unix> win文本文件的人都使用WinSCP ...这是一个很棒的程序,有一个令人恼火的警告,它强行转换为DOS结尾,无法更改。如果您正在使用WinSCP,那么这绝对是一个需要回答的问题,而不是"不要那样做"。
-
@escouten - 在Windows上,你不必拥有crlf中的文件,只是默认情况下可以配置windows编辑器以这种格式保存。更改编辑器选项。在Windows上打开"lf"eol文件不是问题。 (如果您使用记事本作为主编辑,那么,停止。)在许多情况下,您仍然需要"原始"的eol,而不是转换为eol;例如,如果将bash脚本转换为crlf,则无法在cygwin下运行bash脚本;单元测试可能具有此转换"损坏"的输入/输出文件等。
-
@monsto - 当然你可以在没有转换的情况下进行sftp;启用二进制转换,或使用scp。默认情况下,sftp执行文本转换;默认scp做二进制传输;和sftp(包括交互式)可以选择禁用转换。
-
好吧,我认为John Millikin试图解释一下,如果在Windows编辑器上编辑linux文件,你可以改变编辑器行为,告诉像SublimeText这样的东西在它的偏好中:'"default_line_ending":"unix"'
-
+1,当您的团队在同一个仓库中共享.bat和.sh文件时,不要修改EOL。
-
为什么我们不能通过在所有工具中定义LF = CRLF来解决所有线路结束问题?它已经在很多工具中运行,特别是Windows工具。不要害羞,如果您的项目处理换行符,请同时支持它们,并将它们视为平等!
-
您只是假设他们将编辑文件。但是,我想看到你尝试在Linux上编译Windows行结束文件
-
不,如果你有提交者在不同的平台上工作,那就不行了 - 由于EOL的差异我已经不得不将他们核对并从工作区重建(并且不要说"不要那样做")"因为通常没有合法的理由迫使每个人都标准化。"最简单的方法是选择一个EOL标准(我建议
,这样你就可以节省那些额外的字节:-)并确保每个人的每个操作系统都能正确配置客户端。如果正确定义了.gitattributes,Git将始终对开发人员完全透明地做正确的事情。
-
不同意,如果你的主机是Windows,你真的没有太多选择。
-
@RomanStarkov因为它只需要一个工具来生成一个混合的LF + CRLF文件,这会带来很多额外的麻烦;那是在进入文本编码之前。核心问题仍然与几十年来一样 - 没有"纯文本文件"这样的东西,我们应该停止假装存在。当然不会很快发生 - 特别是有这么多的文件格式可以追溯到文本以实现互操作性(至少XML不会假装问题不存在;其他人不是那么快乐的小树:/)。
-
不好的建议。查看非本机行结束可能发生的情况stackoverflow.com/a/53611093/3700414
除非你真的知道自己在做什么,否则你几乎总是想要autocrlf=input。
下面的一些附加背景:
It should be either core.autocrlf=true if you like
DOS ending or core.autocrlf=input if you prefer
unix-newlines. In both cases, your Git repository will
have only LF, which is the Right Thing. The only
argument for core.autocrlf=false was that automatic
heuristic may incorrectly detect some binary as text
and then your tile will be corrupted. So,
core.safecrlf option was introduced to warn a user if
a irreversable change happens. In fact, there are two
possibilities of irreversable changes -- mixed
line-ending in text file, in this normalization is
desirable, so this warning can be ignored, or
(very unlikely) that Git incorrectly detected your
binary file as text. Then you need to use attributes to
tell Git that this file is binary.
上面的段落最初是从gmane.org上的一个帖子中提取出来的,但它已经失败了。
-
为什么它是"正确的事"?
-
core.autocrlf = true是个糟糕的主意。我对该选项没有任何麻烦,而且你必须记住在克隆存储库时设置它。
-
我怀疑这个答案是错误的。这个建议与我在其他地方读到的内容不一致。
-
除非你知道自己在做什么,否则不要使用autocrlf = true。如果你在DOS / Win中开发,那么autocrlf = false将使远程和本地repo之间的结尾保持相同,并且几乎在所有情况下都是最佳选择。
-
@Chris - 如果您的开发人员拥有Windows和多平台项目,而某些多平台开发人员在OSX或Linux上工作,该怎么办?那么最好的选择不应该是autocrlf = true吗?
-
这将是一个有意义的场景,但它不是一个常见的场景,所以这就是为什么它作为默认值没有意义,而是在每个回购的基础上。
-
如果你能够以正确的方式初始化repo(或在某些时候剥离CRLF / CR),则autocrlf = true是好的。许多编辑(特别是Windows下的编辑器?)会产生CRLF并且混合换行存在问题。例如:最小的变化可能导致每一行的转换。当CR与CRLF混合时,git-diff也存在问题。
-
kerneltrap.org链接已损坏,帖子可在此处找到thread.gmane.org/gmane.comp.version-control.git/79726/…
-
@BrettRyan - autocrlf = true永远不是最安全的选择。
-
我不同意,我在许多项目上工作,Windows开发人员可能会弄乱行结尾。我现在在所有项目上使用.gitattributes。
-
Upvoted,有保留。介绍段落是无益的。 core.autocrlf=input是规范的答案。对于大多数用例,core.autocrlf=true和core.autocrlf=false过于热心(......当然是相反但同样可怕的方式)因此本质上是破坏性的。"Git for Windows"应该真正附带"Checkout as-is,提交Unix风格的行结尾"(即core.autocrlf=input)作为其默认的换行策略。它没有。所以我们在这里 - 在2015年的frickin - 仍然无休止地争论这个。
-
谢谢@CecilCurry - 我根据您的反馈澄清了文本。
-
@CecilCurry前几天我发现为什么不呢。有两种Windows不支持Unix风格的换行;记事本(没问题,不要使用它)和Windows窗体文本框。 Visual Studio在各个地方使用它们,包括......来编辑构建前和构建后的脚本。因此,如果您使用Unix风格的换行符,您将丢失Visual Studio中的所有构建脚本换行符。游民。
-
这个链接似乎被打破了。
-
相关:你只是墙上的另一个回车换行
-
正如@BrettRyan所说:通过.gitattributes文件使用存储库范围设置不是更好吗?只是想知道:强迫每个用户在他的机器上处理他的线路结束设置是不方便的......还是有其他缺点?
-
autocrlf坏了;不要使用它(保持虚假)并使用gitattributes和safecrlf = true继承人的核心git开发人员讨论:git.661346.n2.nabble.com/…
在混合环境中(Microsoft + Linux + Mac)获得关于行尾的一致性的两种替代策略:
A.全局所有存储库设置
1)将所有转换为一种格式
1 2
| find . -type f -not -path"./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion' |
2)在Linux / UNIX上将core.autocrlf设置为input或在MS Windows上设置true(存储库或全局)
1
| git config --global core.autocrlf input |
3)[可选]将core.safecrlf设置为true(停止)或warn(唱歌:)以添加额外的保护比较,如果反向换行转换将导致相同的文件
1
| git config --global core.safecrlf true |
B.或每个存储库设置
1)将所有转换为一种格式
1 2
| find . -type f -not -path"./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion' |
2)将.gitattributes文件添加到您的存储库
1 2 3
| echo"* text=auto"> .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending' |
不要担心你的二进制文件--Git应该足够聪明。
有关safecrlf / autocrlf变量的更多信息
-
全局方法==设置并忘记所有回购与每个回购==不要求其他人更改其全局配置。
-
dos2unix是一个命令行工具,取决于您可能必须另外安装的系统
-
它们不是独家的,您可以同时使用这两种方法。此外,使用dos2unix时要非常小心 - 存在损坏.git/index的风险,我们不需要将其应用于每个文件。最好使用find ./ -name"*.html"之类的东西,并指定要将其应用于哪些文件。
-
警告:在运行find行之前,请注意:Git for Windows的dos2unix具有特殊的(IMO愚蠢和危险)行为,没有参数:它不是更改为UNIX,而是切换换行格式(DOS < - > UNIX)
-
另一个警告:不要DOS2UNIX你的.git文件夹。只是说。
尝试将core.autocrlf配置选项设置为true。另请参阅core.safecrlf选项。
实际上听起来像core.safecrlf可能已经在您的存储库中设置了,因为(强调我的):
If this is not the case for the current setting of core.autocrlf, git will reject the file.
如果是这种情况,那么您可能需要检查文本编辑器是否配置为始终使用行结尾。如果文本文件包含LF和CRLF行结尾的混合,则可能会遇到问题。
最后,我觉得简单地"使用你给你的东西"并在Windows上使用LF终止线的建议将导致比它解决的更多问题。 Git有以上选项来尝试以合理的方式处理行结尾,因此使用它们是有意义的。
-
通过.gitattributes文件使用存储库范围设置不是更好吗?只是想知道:强迫每个用户在他的机器上处理他的线路结束设置是不方便的......还是有其他缺点?
在我的Visual&nbsp; Studio&nbsp; 2010项目中检出它们后,使用core.autocrlf=false阻止所有文件被标记为已更新。开发团队的另外两个成员也使用Windows系统,因此混合环境没有发挥作用,但存储库附带的默认设置始终将所有文件标记为克隆后立即更新。
我想底线是找到适合您环境的CRLF设置。特别是因为在Linux盒子上的许多其他存储库中设置autocrlf = true会产生更好的结果。
20多年后,我们仍在处理操作系统之间的线路结束差异......很难过。
-
@ orange80,差距是不幸的,但没有理由把它称为Windows的错。 LF也许从极简主义的角度来看是有道理的;但根据CR和LF的含义,CRLF更有意义。"回车"是指返回到行的开头;"换行"意味着直接向下移动到下一行,而不是到下一行的开头。从语义的角度来看,Windows在两者中都更为正确:移回到开头(CR)然后向下移动一行(LF)。
-
@Kyralessa"更正确"仍假装计算机是打字机,但事实并非如此。顺便说一下。保持打字机类比没有任何意义,因为这不是最终用户将要处理的事情,并且两个字符而不是一个字符是没有意义的。
-
这个派对迟到了几年,但你忽略了CR和LF是光标定位工具的事实。在历史的这一点上,"CR"也可能是"光标回归"。如果我想将光标返回到行的开头,我会告诉应用程序这样做。否则,它需要留在我放的地方。
-
此外,如果CRLF"更正确",因为文本文件换行确实是"向下移动一行"和"移动到行的开头",那么只有CR才会导致文本编辑器覆盖一行。以下行。我知道没有编辑实际上支持这一点,这意味着将CRLF和CR表达为不同的东西的需要并不存在。
-
@avl_sweden在DOS之前这是非常常见的行为,并且由于微软认为兼容性很重要,因此从那时起就一直保持这种状态。它也是美国的标准方式(如pere ASA) - ISO允许CR + LF和LF(因此DOS符合标准);在这两种情况下,自六十年代以来。 Multics(Unix前驱)支持CR用于粗体/打击。现在的许多应用程序(包括.NET的"按行划分"功能)寻找三者中的任何一个(单独的CR,单独的LF,CRLF),并将它们中的每一个视为终点。但是,许多应用程序仍然被文件中的混合行结尾所困惑。
-
@avl_sweden Unicode有八个新的行说明符,所有兼容的应用程序必须支持。但话说再说一遍,Unicode不再假装有类似"纯文本文件"的东西 - 它精确地定义了每个字符在每个系统上的普遍编码方式。可悲的是,Unicode支持仍然相当缺乏,并且似乎仍然非常不受欢迎,尤其是在Unix世界中。程序员通常甚至不会考虑潜在的问题,直到他们咬他们 - 我甚至看到使用LF作为行分隔符的HTTP库,即使文本互联网协议必须使用CRLF ...
这些是与Mac或Linux用户共享代码的Windows和Visual Studio用户的两个选项。有关扩展说明,请阅读gitattributes手册。
* text = auto
在repo的.gitattributes文件中添加:
这将规范化repo中具有LF行结尾的所有文件。
根据您的操作系统(core.eol设置),工作树中的文件将针对基于Unix的系统标准化为LF,对于Windows系统则标准化为CRLF。
这是Microsoft .NET repos使用的配置。
例:
将在回购中标准化为:
在结帐时,Windows中的工作树将转换为:
结帐时,Mac中的工作树将保留为:
Note: If your repo already contains files not normalized, git status will show these files as completely modified the next time you make any change on them, and it could be a pain for other users to merge their changes later. See refreshing a repository after changing line endings for more information.
core.autocrlf = true
如果.gitattributes文件中未指定text,则Git使用core.autocrlf配置变量来确定是否应转换文件。
对于Windows用户,git config --global core.autocrlf true是一个很好的选择,因为:
-
只有在添加到仓库时,文件才会标准化为LF行结尾。如果存储库中没有标准化的文件,则此设置不会触及它们。
-
所有文本文件都将转换为工作目录中的CRLF行结尾。
这种方法的问题是:
-
如果您是autocrlf = input的Windows用户,您将看到一堆LF行结尾的文件。对团队的其他成员而言并不构成危险,因为您的提交仍将使用LF行结尾进行规范化。
-
如果您是core.autocrlf = false的Windows用户,您将看到一堆LF行结尾的文件,您可以将带有CRLF行结尾的文件引入repo。
-
大多数Mac用户使用autocrlf = input并且可能会获得带有CRLF文件结尾的文件,可能来自使用core.autocrlf = false的Windows用户。
-
您对Windows用户的命令是git config --global core.autocrl true。你的意思是git config --global core.autocrlf true。
我花了好几个小时来最好地使用.gitattributes,最终意识到,我不能指望它。
不幸的是,只要存在基于JGit的编辑器(无法正确处理.gitattributes),安全的解决方案就是在编辑器级别强制执行LF。
使用以下anti-CRLF消毒剂。
-
windows / linux客户端:core.autocrlf=input
-
已提交.gitattributes:* text=auto eol=lf
-
已提交.editorconfig(http://editorconfig.org/),这是一种标准化格式,与编辑器插件相结合:
-
https://github.com/editorconfig/
-
https://github.com/welovecoding/editorconfig-netbeans/
击>
---更新2 ---
git客户端的dafaults在大多数情况下都可以使用。即使你只有windows客户端,linux只有客户端或两者兼而有之。这些是:
-
windows:core.autocrlf=true表示在结帐时将行转换为CRLF,并在添加文件时将行转换为LF。
-
linux:core.autocrlf=input表示不在checkout上转换行(不需要因为文件应该用LF提交),并在添加文件时将行转换为LF(如果需要)。
该属性可以设置在不同的范围内。我建议在--global范围内明确设置,以避免最后描述的一些IDE问题。
1 2 3 4 5
| git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf |
此外,我强烈反对使用git config --global core.autocrlf false(如果你只有Windows客户端)与git文档的建议形成对比。设置为false将在repo中提交具有CRLF的文件。但实际上没有理由。你永远不知道是否需要与linux用户共享项目。此外,对于加入项目而不是使用默认值的每个客户端,这是一个额外的步骤。
现在,对于某些特殊情况的文件(例如*.bat *.sh),您希望使用LF或CRLF检出这些文件,可以使用.gitattributes
总结一下,最佳做法是:
-
确保在git repo上使用LF提交每个非二进制文件(默认行为)。
-
使用此命令确保没有使用CRLF提交文件:git grep -I --files-with-matches --perl-regexp '
' HEAD(注意:在Windows客户端上仅通过git-bash工作,并且只有在./configure中使用--with-libpcre进行编译时才能在Linux客户端上工作)。
-
如果通过执行上述命令找到任何此类文件,请更正它们。
-
仅使用最低.gitattributes
-
指示用户将上述core.autocrlf设置为其默认值。
-
存在.gitattributes时不要100%计算。 IDE的git-clients可能会忽略它们或对它们进行不同的处理。
如上所述,可以在git属性中添加一些内容:
1 2 3 4
| # Always checkout with LF
*.sh text eol=lf
# Always checkout with CRLF
*.bat text eol=crlf |
我认为.gitattributes的一些其他安全选项,而不是使用二进制文件的自动检测:
-
-text(例如*.zip或*.jpg文件:不会被视为文本。因此不会尝试行结束转换。可能通过转换程序可以实现差异)
-
text !eol(例如*.java,*.html:处理为文本,但未设置eol样式首选项。因此使用客户端设置。)
-
-text -diff -merge(例如*.hugefile:未视为文本。无差异/合并可能)
---上一次更新---
一个错误地提交文件的客户端的一个痛苦的例子:
netbeans 8.2(在Windows上)将错误地使用CRLF提交所有文本文件,除非您已将core.autocrlf明确设置为全局。这与标准的git客户端行为相矛盾,并且在更新/合并时会导致很多问题。这使得某些文件看起来不同(尽管它们不是),即使你还原也是如此。
即使您已将正确的.gitattributes添加到项目中,也会发生netbeans中的相同行为。
在提交后使用以下命令,至少可以帮助您及早发现您的git repo是否存在行结束问题:git grep -I --files-with-matches --perl-regexp '
' HEAD
-
我同意你的看法,这是最好的方法,没有人应该在没有LF支持的情况下使用编辑器。但要小心你的.gitattributes行,它在Git <2.10中有意外的结果,请参阅stackoverflow.com/a/29508751/2261442
-
Darn it ...我有很多答案,我主张git config --global core.autocrlf false,并建议只在.gitattributes指令中处理eol。
这只是一种解决方案:
在正常情况下,请使用随git一起提供的解决方案。这些在大多数情况下都很有效。如果您通过设置.gitattributes在基于Windows和Unix的系统上共享开发,则强制为LF。
在我的案例中,有超过10名程序员在Windows中开发项目。该项目已通过CRLF签入,并且没有强制选择LF的选项。
有些设置在我的机器上内部写入,对LF格式没有任何影响;因此,在每次小文件更改时,一些文件全局更改为LF。
我的解决方案
Windows的机器:
让一切都保持原样。什么都不关心,因为你是一个默认的Windows'孤狼'开发者,你必须像这样处理:"广阔的世界里没有其他系统,是吗?"
Unix的机
将以下行添加到配置的[alias]部分。此命令列出所有已更改(即已修改/新)的文件:
1 2 3
| lc ="!f() { git status --porcelain \
| egrep -r "^(\?| ).\*\\(.[a-zA-Z])*" \
| cut -c 4- ; }; f" |
将所有这些已更改的文件转换为dos格式:
可选......
为此操作创建一个git hook以自动执行此过程
使用params并包含它并修改grep函数以仅匹配特定的文件名,例如:
1
| ... | egrep -r"^(\?| ).*\.(txt|conf)" | ... |
使用其他快捷方式随意使其更方便:
1
| c2dos ="!f() { unix2dos $(git lc) ; }; f" |
...并通过键入来解雇转换后的内容