git-submodule-rewrite: enhance performance by using git-filter-repo

[hugoam]

I am studying using this script, but it just took two hours to process one branch, and it's configured to operate on a temporary path that it deletes afterwards, so as soon as I'll want to merge another branch, I think I'm in for another two hour processing per branch While googling around, I found something quite promising under the name of git filter-repo (https://github.com/newren/git-filter-repo/) whose use is even advised in the documentation of git filter-branch itself So the question is, how hard would it be to change the script to use filter-repo instead of filter-branch and would there be any reason not to ? While glancing at it, it seems like it could solve a few problems at once: first, I would not have to reprocess the commits for each branch (granted I hook a non-temporary working path in the arguments too instead of the temp dir), and could process the whole repository at once, and second, the perf is promised to be much, much better And then the corollary question would be, if I change the script to use filter-repo, would you be interested in a PR ?

[jeremysears]

That seems reasonable. My original use case with this repo was pretty narrow, but many people have applied it to much more extensive usage patterns. I'd be happy for someone to enhance the code. However, this repo is in desperate need of some unit tests, and making such an significant change would likely require some. Are you interested in contributing?