4 ms·
Rebase is already lightning fast for me... Even on projects with thousands of commits! How big does your repo have to get before rebases are sluggish?
by umvi 5y ago
Rebase is already lightning fast for me... Even on projects with thousands of commits! How big does your repo have to get before rebases are sluggish?
- mb7733 5y agoI 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).
- jeppesen-io 5y agoyeah, 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
- OJFord 5y agoYes, it's equivalent to checkout and cherry-pick. (And to be exact, then possibly branch -f and checkout, depending what was rebased.)
- MarkSweep 5y agoIt’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.
- cerved 5y agoa rebase checkouts out every file on every commit it's rebasing, it's quite slow