Re: [PATCH 0/2] Add --no-filters option to git-add

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Feb 19, 2021, 22:36 UTC
Message-ID: <YDA9WjWOjkqlsALc@camp.crustytoothpaste.net>
In-Reply-To: <pull.880.git.1613758333.gitgitgadget@gmail.com>

On 2021-02-19 at 18:12:11, Andrej Shadura via GitGitGadget wrote:

Show 20 quoted lines

> 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