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

Question

如果将 .gitattributes 文件添加到给定目录，其内容如下:

*.txt    text

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

再次解释一下，这个 .gitattributes 文件是一种绝对万无一失的方法来防止新的 CRLF 行被提交到 *.txt 文件吗在包含 .gitattributes 文件的目录中？我想说服我的同事们，.gitattributes 文件已经足够了，不需要采取进一步措施来排除 CRLF(例如服务器端 Hook )。

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

Answer 1

不容易通过gitattributes , 因为 negative pattern 是被禁止的。

实际上，这几天(2013 年 3 月)提出了一个补丁到 Make !pattern in .gitattributes non-fatal .

所以你需要把像 *.txt 这样的全局规则只放在 .gitattributes 文件中，这些文件存在于你知道你的子目录中不需要 CRLF。

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

---

kostmo提及 in the comments EGit bug 421364 :

Until this is implemented, I recommend this setup:

1. For each Eclipse project, go to Properties > Resource and change "New text file line delimiter" to Other: Unix. Commit the resulting .settings/org.eclipse.core.runtime.prefs files.
2. Don't configure any .gitattributes or "core.autocrlf" for Git.
   This means that files will have the same line endings in the working directory as in the repository. Git and EGit will not convert any file contents.

With 1., all new files that are created in Eclipse will have correct (LF) line endings, even when created by a user on Windows.

For files that are already in your repository with CRLF, you can fix them and commit the result. I recommend using dos2unix or fromdos on the command line.

注意:该问题 ( bug 421364 ) 刚刚(2014 年 3 月 25 日)被重新认定为 bug 342372 的副本通过 Lars Vogel .

因此，JGit 对.gitattributes 的支持是“指定的”，但它的实现仍在进行中。

正在审查实现(2015 年 1 月):

• "review 1614 "添加对 .gitattributes 的基本支持

Core classes to parse and process .gitattributes files including support for reading attributes in WorkingTreeIterator and the dirCacheIterator.

• "review 35377 "在 treewalk 上添加 git 属性计算

Adds the getAttributes feature to the tree walk.
The computation of attributes needs to be done by the TreeWalk since it needs both a WorkingTreeIterator and a DirCacheIterator.

---

2018 年 8 月更新:上述错误 ( bug 342372 ) 取决于 JGit bug 537410 ，刚刚得到解决。
“JGit rebase 和 stash 不保留行结尾”

The problem is that the ResolveMerger during processEntry() does not remember the CheckoutMetadata (in which JGit stores filters and eol-attributes) for the files and then checks them out in checkout() ignoring any attributes or filters.

ResolveMerger.cleanUp() has the same problem.

JGit commit 4027c5c (来自 review 127290 )应该可以解决这个问题。
感谢 Thomas Wolf 和 active contributor to JGit .

这让 EGit 有了希望:

EGit in general leaves all this eol handling in staging/merging/checkout to JGit.
The only places where EGit has to care about it is in the compare framework when it has to read index entries itself, and there it already properly handles CheckoutMetadata.