问题标签 [eol]

是否可以git merge忽略行尾差异？

也许我问错了问题......但是：

我尝试了 uisng config.crlf input，但事情变得有点混乱和失控，特别是当我在事后应用它时。

一方面，事后应用此配置似乎不会影响在应用此选项之前提交到存储库的文件。另一件事是突然间所有的提交都会导致大量关于 CRLF 被转换为 LF 的恼人警告消息。

老实说，我真的不在乎使用什么换行符，我个人更喜欢 Unix 风格\n，但无论如何。我所关心的git merge只是变得更聪明一点，并忽略行尾的差异。

有时我有两个相同的文件，但 git 会将它们标记为冲突（并且冲突是整个文件），因为它们使用了不同的行结束符。

更新：

我发现git diff接受一个--ignore-space-at-eol选项，是否也可以让git merge使用这个选项？

例如，当我创建一个新文件时：

如何在 PHP 中设置它的编码（utf-8 或 shift-jis 或 euc-jp）和换行符（LF 或 CR+LF 或 CR）？

我有一个托管在 Linux 上的 subversion 存储库，但只能通过 Windows 客户端访问，因为它是大型 Windows 应用程序的源。

如果我可以使用 git-svn（由 msysgit 提供）在这个存储库上工作，那就太棒了。

我有一段时间试图让存储库不让自己陷入 Windows 风格的行尾。

svn clone签出 git 存储库后：

• core.autocrlf = true显示对存储库中实际使用的任何文件的修改LF。
• core.autocrlf = input显示对存储库中实际使用的任何文件的修改LF。
• core.autocrlf = false显示对所有内容的修改。

这里最好的选择是什么？我应该使用core.autocrlf = true并提交LF对CRLF受影响文件的更改吗？

我非常接近认输，只是将我的 Subversion 工作副本放入 git 存储库。这将是一个糟糕的解决方案，但至少允许本地分支和存储。在将文件添加到 subversion 时，继续添加文件显然会变得非常痛苦。

编辑：对于那些有兴趣的人。git-svn如果你在 Windows 上，那是一种皇家痛苦。hasen j 在下面的回答可能是正确的，但如果不引起团队中其他开发人员的愤怒，我就不能听从他的建议。

我基本上放弃了这个问题，因为它不会导致合理的结果。希望下一个 Google Summer of Code 能够吸引那些想要获得“Windows 上正确的 git-svn 支持”项目的人。请参阅http://git.or.cz/gitwiki/SoC2009Ideas#Propergit-svnsupportonWindows

有没有办法在 .net 框架中获取当前系统的换行符？

我的程序可以接受具有 \n、\r\n 或 \r 换行符的数据（例如 Unix、PC 或 Mac 样式）

构建将匹配任何编码的正则表达式的最佳方法是什么？

或者，我可以在输入上使用universal_newline 支持，但现在我有兴趣看看正则表达式会是什么。

我们一直在同时处理一些文件。有时，当我们“svn up”时，我们会看到某些文件的每一行都附加了“^M”的文件。我们原本互相指责对方的编辑>_>。

从那以后，我们将其范围缩小到当存在冲突时“svn up”。如果我们隔离冲突文件并且 svn 不会出现“^M”。svn log/diff 中没有“^M”出现。它完全奇怪，对吧？

希望有人可能以前见过这个并知道一种解决方法。IDK，它可能无法在其他人的设置上重现。如果有帮助，我们正在使用 Subversion 1.4.4。

感谢您的阅读，感谢您的任何评论。

到目前为止，我们工作中的纯桌面产品一直使用 JDK 1.4.2（产品附带的也是 1.4.2 JRE）。我试图说服管理层让我们升级到更新的版本，以获得性能、API/功能和开发人员舒适度的好处。

由于 1.5 已经到了 EOL 过渡，我正在考虑直接升级到 1.6.0_10（选择更新 10，因为它是主要的）。就代码而言，所有编译错误只是enum我重命名的变量名，并且产品运行良好。

问题是

• 是否推荐/罚款此升级，即跳过 1.5 ？有什么问题吗
• 如果是，那么我应该升级到 1.6u10 还是可用的最新 1.6？

谢谢

在gvim窗口中，如果我有文本，CRLF eol那么文本将显示^M在每行的末尾。

如何从显示中“隐藏”那个特殊字符？

:set nolist command """不会驳回它。

更新

我做:set fileformats=unix,dos了一个列表。起初它不起作用，但我关闭了文件并再次重新打开它，它起作用了。

默认情况下，我将文件格式设置为仅 unix 值。

感谢您的回答。

我有一个记录解析器，它抛出几个异常之一来指示哪个规则失败。

前题：

我们使用position_iteratorfrom Spirit.Classic，所以下面的流插入操作符很方便。

该模板err_t排除了用于抛出与不同形式的解析失败相关的异常的样板。

err_t与它们的包装一起使用的异常：

语法寻找简单的序列。没有eps，start规则会失败，而不是a空输入。

在my_parse中，我们将流的内容转储到 a 中std::string并用于position_iterator跟踪解析的位置。

最后是主程序

上面的代码抛出MissingA：

我认为船长可能已经消耗了换行符，但尝试lexeme[eol]却产生了相同的结果。

我一定遗漏了一些明显的东西，因为这似乎是最简单的解析器之一。我究竟做错了什么？

不应该一个简单eol的伎俩吗？

输出：

为什么后两者会失败？

相关问题：

使用 boost::spirit，我如何要求记录的一部分单独存在？