automatic rebasing is nice but how does graphite/ et al. solve the issue of creating a rebase conflict when working in feedback in the middle of the stack? And

automatic rebasing is nice but how does graphite/ et al. solve the issue of creating a rebase conflict when working in feedback in the middle of the stack? And big prs have usually the property that you cannot just incrementally merge parts to main without breaking main. An api producer might change at one place and the accompanied change for an api consumer changes in another. Splitting up prs so the parts can be merged is significant work and part of the reason why big prs happen in the first place. I dont see how this works without a "virtual" main branch target that only gets merged to real main when the whole merge is done but then you have to reconcile differences for things that happened on main in between.