consider.  See the
     "DISCUSSION" section of the git filter-repo manual page for more
     details.

* Annotated tags can be accidentally converted to lightweight tags,
  due to either of two issues:

  ** Someone can do a history rewrite, realize they messed up, restore
     from the backups in refs/original/, and then redo their
     git-filter-branch command.  (The backup in refs/original/ is not a
     real backup; it dereferences tags first.)

  ** Running git-filter-branch with either --tags or --all in your
     <rev-list-options>.  In order to retain annotated tags as
     annotated, you must use --tag-name-filter (and must not have
     restored from refs/original/ in a previously botched rewrite).

* Any commit messages that specify an encoding will become corrupted
  by the rewrite; git-filter-branch ignores the encoding, takes the
  original bytes, and feeds it to commit-tree without telling it the
  proper encoding.  (This happens whether or not --msg-filter is
  used.)

* Commit messages (even if they are all UTF-8) by default become
  corrupted due to not being updated -- any references to other commit
  hashes in commit messages will now refer to no-longer-extant
  commits.

* There are no facilities for helping users find what unwanted crud
  they should delete, which means they are much more likely to have
  incomplete or partial cleanups that sometimes result in confusion
  and people wasting time trying to understand.  (For example, folks
  tend to just look for big files to delete instead of big directories
  or extensions, and once they do so, then sometime later folks using
  the new repository who are going through history will notice a build
  artifact directory that has some files but not others, or a cache of
  dependencies (node_modules or similar) which couldn't have ever been
  functional since it's missing some files.)

* If --prune-empty isn't specified, then the filtering process can
  create hoards of confusing empty commits

* If --prune-empty is specified, then intentionally placed empty
  commits from before the filtering operation are also pruned instead
  of just pruning commits that became empty due to filtering rules.

* If --prune-empty is specified, sometimes empty