The SAFETY section of git-filter-branch(1) notes:
git-filter-branch is riddled with gotchas resulting in various ways to easily corrupt repos or end up with a mess worse than what you started with
And then goes on to list several examples. With this scary note now fresh in mind, I’m curious if there are on the other hand legitimate use cases for employing filter-branch over the likes of rebase -i
Using git-filter-branch is definitely risky, but all the risks can be mitigated by making sure you’ve pushed a backup of your original branch to a remote (and then removing the remote for extra safety). The main use case I break it out for occasionally is when I went to merge a project that started out spread across multiple repos into one monorepo with history preserved. You can use filter-branch to first translate each repo into having all its content under a root subpath, and then merge all the repos together into one where blame still works correctly
Interesting. I would personally probably tackle that use case with git-subtree, which makes that particular problem dead simple. e.g.,
git subtree --prefix polyrepo1-dir add git://git.example.com/polyrepo1.git main
git subtree --prefix polyrepo2-dir add git://git.example.com/polyrepo2.git main
Though after exploring that idea more I’ve discovered that rebasing after a subtree merge is really ugly business for reasons that your filter-branch example would completely mitigate