On 2021-02-19 at 18:12:11, Andrej Shadura via GitGitGadget wrote: > It is possible for a user to disable attribute-based filtering when > committing by doing one of the following: > > * Create .git/info/attributes unapplying all possible transforming > attributes. > * Use git hash-object and git update-index to stage files manually. > > Doing the former requires keeping an up-to-date list of all attributes which > can transform files when committing or checking out. Doing the latter is > difficult, error-prone and slow when done from scripts. > > Instead, similarly to git hash-object, --no-filter can be added to git add > to enable temporarily disabling filtering in an easy to use way. > > These patches: > > * Add new flag ADD_CACHE_RAW to add_to_index() > * Add new flag HASH_RAW to index_fd() > * Make git hash-object use the new HASH_RAW flag for consistency > * Add tests for the new git-add option. I'm interested in your use cases here. While I agree that this is an interesting feature, it also means that practically, a user who checks out a file that's added this way may find that git status marks it as perpetually modified until a properly cleaned version is committed. Moreover, even "git reset --hard" won't fix this situation. We see this problem extremely frequently with Git LFS where people change the .gitattributes file but don't run "git add --renormalize ." and then end up with this problem. However, it's not limited to Git LFS in particular; anything that uses filters, working tree encodings, or end of line attributes can be affected. So I think that while this might be a useful escape hatch for users, I definitely want to see a compelling rationale for it and a big warning in the documentation and an update to the relevant entry in the Git FAQ before we accept such a patch. -- brian m. carlson (he/him or they/them) Houston, Texas, US