3

如果将.gitattributes文件添加到给定目录，则其内容完全相同：

*.txt    text

是否有任何可能的方式可以将新文件或先前规范化的文件（例如所有 LF 行结尾）提交到该目录而不进行规范化？即，在指定模式启用后，是否有任何可能的方式可以将新的 CRLF 行结尾引入存储库？.gitattributestext

再次解释一下，这个.gitattributes文件是防止新的 CRLF 行被提交到包含该文件的目录中的文件的绝对万无一失的方法吗？我想说服我的同事该文件是完全足够的，并且没有必要采取进一步措施来排除 CRLF（例如服务器端挂钩）。*.txt.gitattributes.gitattributes

答案应该要么确认不可能覆盖由 指定的行尾行为.gitattributes，要么提供一个反例来解释如何绕过.gitattributes文件并潜入某些 CRLF 行尾。

4

2 回答 2

2

不容易通过gitattributes，因为禁止负面模式。

实际上，这天（2013 年 3 月）提出了一个补丁来制作非致命的!pattern.gitattributes。

因此，您需要放置一个全局规则，例如*.txt仅在您知道不需要 CRLF.gitattributes的子目录中存在的文件中。

并在内容混合的目录中保留更细粒度的text规则。.gitattributes

kostmo在评论中提到了EGit 错误 421364：

在此实施之前，我推荐此设置：

  1. 对于每个 Eclipse 项目，转到Properties > Resource并将“ New text file line delimiter”更改为Other: Unix. 提交生成的.settings/org.eclipse.core.runtime.prefs文件。
  2. 不要为 Git配置任何.gitattributes或“ ”。 这意味着文件在工作目录中的行尾与存储库中的行尾相同。Git 和 EGit 不会转换任何文件内容。core.autocrlf

使用 1.，在 Eclipse 中创建的所有新文件都将具有正确的 ( LF) 行结尾，即使是由 Windows 上的用户创建的。

对于已经在您的存储库中的文件CRLF，您可以修复它们并提交结果。我建议在命令行上使用dos2unixor 。fromdos

注意：该问题（错误 421364）刚刚（2014 年 3 月 25 日）被 Lars Vogel 重新认定为错误342372的副本。

因此，.gitattributesJGit 的支持是“分配的”，但它的实现是仍在进行中.

正在审查实施（2015 年 1 月）：

  • “评论1614 ”添加基本支持.gitattributes

解析和处理.gitattributes文件的核心类，包括支持读取 WorkingTreeIterator 和 dirCacheIterator 中的属性。

将getAttributes特征添加到树行走。
属性的计算需要由 the 完成，TreeWalk因为它需要 aWorkingTreeIterator和 a DirCacheIterator。

2018 年 8 月更新：上面提到的错误（错误 342372）取决于刚刚解决的JGit 错误 537410 。
“ JGit rebase 和 stash 不保留行尾s”

问题是ResolveMerger期间processEntry()不记得CheckoutMetadata文件的（JGit 存储过滤器和 eol 属性），然后在checkout()忽略任何属性或过滤器的情况下检查它们。

ResolveMerger.cleanUp()有同样的问题。

JGit commit 4027c5c（来自评论 127290）应该可以解决这个问题。
感谢Thomas Wolf是 JGit的积极贡献者。

这给 EGit 带来了希望：

EGit 通常将所有这些 eol 处理留在暂存/合并/结帐给 JGit。
EGit 唯一需要关心的地方是在比较框架中，它必须自己读取索引条目，并且它已经正确处理了CheckoutMetadata.

于 2013-06-18T07:01:45.130 回答
1

再次解释一下，这个 .gitattributes 文件是绝对万无一失的方式吗

不会。Git 有很多便利可以让日常任务变得简单，并且可以将减速带放在有问题的地方，但它不会限制您对自己的 repo 的控制。

我想说服我的同事 .gitattributes 文件完全足够，并且不需要进一步的措施来排除 CRLF（例如服务器端挂钩）。

它们是必要的。没有人可以控制其他人在自己的仓库中所做的事情。

git update-index --cacheinfo \
        100644,`git hash-object -w --no-filters path/to/file`,path/to/file

来自git hash-object 文档

--no-filters
按原样散列内容，忽略属性机制选择的任何输入过滤器，包括行尾转换。如果文件是从标准输入读取的，那么这总是隐含的，除非给出了 --path 选项。

于 2015-01-09T01:56:17.787 回答