Why does 'git status' ignore the .gitattributes clean filter?

不想你离开。 提交于 2019-12-18 12:28:10

问题


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?


回答1:


git add adds the file to the index,1 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.2

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.


1More 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.

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



来源:https://stackoverflow.com/questions/19807979/why-does-git-status-ignore-the-gitattributes-clean-filter

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!