It’s not the number of commits, it’s the number of files changing that can slow you done. If you are in a monorepo where tens or hundreds of thousands of files are changing everyday, checking out the old branch before rebasing can take a while.

That said, this is only a problem at my work. Even the largest of open source repos I have worked on have been mostly fine with Git’s slow rebase implementation.

I don't even think that rebase would get slower as the repo grows. It would only depend on how many commits are being rebased (and the contents of those commits).

yeah, I was thinking the same thing. I've never benchmarked it, but I assume rebase speed is a result of the delta of commits between your branch and the branch you're rebasing against, not the absolute size of commits for a repo

More interested in hearing more about the use case for this tool. AFAIK Git was created for use with Linux, which is a large codes base with lots of churn. One would asume rebase would work with a large codebase like that

a rebase checkouts out every file on every commit it's rebasing, it's quite slow