为什么'git status'忽略.gitattributes clean filter？ [英] Why does 'git status' ignore the .gitattributes clean filter?

问题描述

我有 .gitattributes清洁过滤器
$ b

  $ cat .git / config 
 在文件提交前删除文件中的所有注释。
 ] 
 clean =grep -v'^＃'
 
 $ cat .gitattributes 
 * filter = cleancomments 
  

我有一个包含以下内容的文件'test'（在仓库中提交）：

pre > 这是一个随机内容


的文件现在我对'测试'并添加评论：

 这是一个随机内容
＃和一些评论
＃像这样
  

git status 现在告诉我：

 修改：test 
  

但是 git diff 是空的（因为它应该）。

对我来说为什么git状态不使用过滤器来决定文件是否被修改，但我认为这是它的实现方式。

对我而言，真正神秘的是：

如果我这样做：

  git add test 
  

然后突然文件'test'不再被标记为已修改并且它不会出现在git索引中。这是为什么？

解决方案

git add 将文件添加到索引， ¹ 但首先通过任何必需的过滤器运行它。

索引包含文件的磁盘名称和真实名称哈希作为一个blob）以及目录 stat 值和一对git散列值（原始和过滤）以及其他一些位和bobs。一旦添加 -ed， git status 可以从索引数据中知道文件现在是最新索引和索引本身在存储库中是最新的，因为blob的哈希匹配 HEAD 提交哈希。

<但是，如果你修改了一些文件，一些关键的 stat 数据发生了变化，使得git认为索引已经过期，并且 git status 会再一次认为它需要 git add -ed。 ²

这里的一般想法似乎是 git status 不会写任何东西（甚至是索引）。如果 git update-index --refresh 会更新工作目录/清理条目配对，但它似乎不会。

---

¹ 更确切地说， git add 因此是回购中的真实姓名，并且当且仅当它不存在时才将该对象添加到回购。哈希值现在是已知的，可以根据需要存储在索引中。散列值在做过滤和散列之后才是未知的，即 git status 不知道它。

² 如果使用诸如 - 承担 - 不变和/或 core.ignorestat 。

I have a .gitattributes clean filter to remove all comments from a file before committing.

$ cat .git/config
[filter "cleancomments"]
    clean = "grep -v '^#'"

$ cat .gitattributes
*   filter=cleancomments

And I have a file 'test' with following content (committed in the repository):

This is a file with random content

Now I make a modification to 'test' and add comments:

This is a file with random content
# and some comments
# like this

git status now tells me:

modified:   test

but git diff is empty (as it should).

It is not completely clear to me why git status does not use the filter to decide if a file has been modified or not, but I assume this is how it is implemented.

What is really mysterious to me is following:

If I do this:

git add test

Then suddenly the file 'test' is no longer marked as modified and it does not appear in the git index. Why is this?

解决方案

git add adds the file to the index,¹ but runs it through any required filters first.

The index contains the file's on-disk name and "true name" (its git hash as a "blob") along with directory stat values and a pair of git hash values (original and filtered), plus some other bits and bobs as needed. Once add-ed, git status can tell from the index data that the file is now "up to date" in the index, and the index itself is up to date in the repository as the blob's hash matches the HEAD commit hash.

If you modify the file some more, though, some key stat data changes, making git think the index is out of date, and git status will once again think it needs to be git add-ed.²

The general idea here seems to be that git status does not write anything (even the index). It might be nice if git update-index --refresh would update the work-dir/cleaned-entry pairing, but it does not seem to.

---

¹More precisely, git add computes the hash—and hence the "true name" in the repo—and then adds the object to the repo if and only if it's not already present. The hash value is now known and can be stored in the index as needed. The hash value is unknown until after doing the filtering and hashing, i.e., git status doesn't know it.

²There are more subtleties here if you use things like --assume-unchanged and/or core.ignorestat.

这篇关于为什么'git status'忽略.gitattributes clean filter？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！