是否可以提交违反.gitattributes指定的行结束行为的文件？

Question

如果将.gitattributes文件添加到给定目录，则具有以下内容：

*.txt    text

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

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

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

Answer 1

不容易通过gitattributes，因为否定模式是被禁止的。

实际上，今天（2013年3月）向Make !pattern in .gitattributes non-fatal提出了一个补丁。

因此，您需要将*.txt这样的全局规则仅存储在您已知的子目录中的.gitattributes个文件中，您将不需要CRLF。

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

---

kostmo提到in the comments EGit bug 421364：

  

在此实施之前，我建议使用此设置：

     

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

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

     

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

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

因此，JGit对.gitattributes的支持是“已分配”，但其实现仍在进行中。

正在审核实施情况（2015年1月）：

• “review 1614”为.gitattributes添加基本支持

  

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

• “review 35377”在树木行道上添加git属性计算

  

将getAttributes功能添加到树步行中   属性的计算需要由TreeWalk完成，因为它需要WorkingTreeIterator和DirCacheIterator。

---

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

  

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

     

checkout()也有同样的问题。

JGit commit 4027c5c（来自review 127290）应该解决这个问题 感谢 Thomas Wolf 和active contributor to JGit。

这为EGit带来了希望：

  

EGit通常会将所有这些eol处理留在JGit的暂存/合并/结账中   EGit必须关心它的唯一地方是在比较框架中，当它必须自己读取索引条目时，它已经正确处理ResolveMerger.cleanUp()。

Answer 2

  

再说一遍，这个.gitattributes文件是绝对万无一失的

没有。 Git有很多便利，可以轻松完成常规任务，并将速度障碍放在可疑的事情上，但它不会限制你对自己仓库的控制。

  

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

他们是必要的。没有人可以控制别人在自己的回购中所做的事情。

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

来自git hash-object docs

  

<强> - 无过滤器
  按原样哈希内容，忽略属性机制选择的任何输入过滤器，包括行尾转换。如果从标准输入读取文件，则总是暗示，除非给出了--path选项。