Daniel Höpfl <daniel@xxxxxxxxx> writes: > Hello there, > > What did you do before the bug happened? (Steps to reproduce your issue) > git filter-branch -f --env-filter '' --tag-name-filter cat -- HEAD > > What did you expect to happen? (Expected behavior) > See below (difference). > > What happened instead? (Actual behavior) > When using git filter-branch, the following message is shown: > > ----------8<----------------------------------------------------- > WARNING: git-filter-branch has a glut of gotchas generating mangled history > rewrites. Hit Ctrl-C before proceeding to abort, then use an > alternative filtering tool such as 'git filter-repo' > (https://github.com/newren/git-filter-repo/) instead. See the > filter-branch manual page for more details; to squelch this warning, > set FILTER_BRANCH_SQUELCH_WARNING=1. > ----------8<----------------------------------------------------- > > You can suppress this by setting the environment variable shown. > > What's different between what you expected and what actually happened? > > Normally, when git introduces this kind of change, there is a > git config variable that one can set to suppress it. > That way one has fine grade control when to suppress it (one repo only...globally). I think this comes from 9df53c5d (Recommend git-filter-repo instead of git-filter-branch, 2019-09-04). FWIW, I personally do not think an environment is a worse choice over configuration variable in this particular case. The large scale rewriting of the entire history in the repository by its nature is an one-off operation that ought to happen only rarely, so a one-shot $ FILTER_BRANCH_SQUELCH_WARNING=1 git filter-branch ... that reminds the user every time would be more appropriate than a configuration variable that has a more permanent squelching effect. If it were a new command line option may have been even better, as an environment variable can be defined in .*rc and forgotten, but a command line option needs to be typed every time and would serve as a better reminder (yes, I know it can also be aliased away, so it may not make much practical difference either way). But I'll let the author of the feature to comment. Thanks.
