search

facebook / sapling

A Scalable, User-Friendly Source Control System.
https://sapling-scm.com
GNU General Public License v2.0
6.1k stars 279 forks source link

Rebasing in a repo with submodules is really slow/barely usable especially when there's a merge conflict #870

Closed aorenste closed 5 months ago

aorenste commented 5 months ago

I'm using Sapling with pytorch (https://github.com/pytorch/pytorch). Mostly it works really well but one problem that happens is when rebasing a diff on the main branch the submodules can rebase really slowly. This seems especially bad when there's a merge conflict (on the main branch - not in one of the submodules).

Locally I have a diff stack with around 15 diffs in a tree. The command I'm running is simply sl rebase -d remote/viable/strict (or some variation on that: sl rebase -d remote/viable/strict~20). When there's a conflict which I fix and then "sl resolve -m ; sl rebase -c".

Sometimes the "rebase -c" will take forever - literally - on my devgpu I once let it run overnight (>12h) and it still didn't finish and was taking 0% of the CPU.

When it feels like it's blocked in this way it seems to help "kick it" - if I Ctrl-C and re-run the "sl rebase -c" it seems like it will continue from where it left off and will get beyond where it was stalled previously. On a recent rebase I had to do this about 5 - 10 times for it to finish.

muirdm commented 5 months ago

Redirecting to internal channels.