The question is how to we maintain the triviality of the operation: fundamentally a find-and-replace. If there was just one big PR (

main

<-

PR123

), the author would just do a find-and-replace and be good to go. Because of the stacking, this operation is now more burdensome. I am hoping there is a way to reduce the burden.

brainstorming, and forgetting about Graphite but just thinking about Git: the situation is like I have a Git history like

main

<-

C1

<-

C2

<-

C3

and then I do a find-and-replace. I could commit the modifications due to the find-and-replace separately and get at the situation:

main

<-

C1

<-

C2

<-

C3

<-

R1

<-

R2

<-

R3

and now I want to re-order the commits automatically so that they can be in the appropriate parts of the stack.

More brainstorming. You have

main

<-

C1

<-

C2

<-

C3

and you turn it into (

main

<-

C123

, the_structure_you_lost) Then you do the trivial find-and-replace (

main

<-

C123_fixed

, the_structure_you_lost) and you'd like to turn that into

main

<-

C1_fixed

<-

C2_fixed

<-

C3_fixed

Also normally I would just open a new PR on top of

PR3

for the renaming operation, which might be good enough depending on the engineering process

(I am also thinking about other more advanced ways to support refactoring PRs better, might take a long time for those to become reality though)

I will have to look at

git absorb

!