Re: [PATCH v4 00/12] rebase: update branches in multi-part topic

Derrick Stolee <derrickstolee@github.com> writes:

I am not aiming to flatten P and Q into a single strand of pearls. That would defeat the point of "git log --oneline --first-parent" that can be used to view "master..Q", whose output would be "at the bottom the topic P lies there, and on top there are 3 patches".

P's may be your ds/branch-checked-out topic while Q's may be this topic. Other people may find bugs, improvements and a room for unwanted churns in the former, and P may gain a few more commit, in which case M thru Q3 needs to be rebuilt.

In a manual procedure, when I realize that P will gain a few more patches (or gets rewritten):

 * find what other topics depend on P and make a mental note (i.e. Q
   needs to be rebuilt)

 * perform an equivalent of "git rebase -i --onto A P", but without
   using "git rebase".

   - git checkout P
   - git checkout --detach master...	;# reuse the same base
   - git am -s				;# apply
   - git rebase -i                      ;# minor fix-up while queuing
   - git range-diff @{-1}...		;# sanity check
   - make test				;# further sanity check
   - git checkout -B @{-1}		;# update P to the new round
   - git range-diff @{1}...             ;# final sanity check

   this rebuilds P1, P2, and P3 into a new series on A

 * for each topic that needs rebuilding (i.e. Q), find M and rebuild
   it

   - git checkout Q
   - git checkout --detach master...	;# reuse the same base
   - git merge --into Q P		;# recreate M with updated P
   - git rebase --onto HEAD M Q		;# rebuild Q
   - git checkout -B @{-1}		;# update Q to sit on top of new P
   - git range-diff @{1}...		;# sanity check (should be empty)

I suspect that a creative use of "git rebase --rebase-merge master Q" should allow me to get there. Here is an outline of the todo list you'd get out of "git rebase --rebase-merge -i v2.37.0" while the topic ds/rebase-update-ref is checked out:

---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- label onto

# Branch ds-branch-checked-out reset 5ed49a75f3 # Merge branch 'os/fetch-check-not-current-branch' pick 31ad6b61bd branch: add branch_checked_out() helper pick d2ba271aad branch: check for bisects and rebases ... pick 9bef0b1e6e branch: drop unused worktrees variable label ds-branch-checked-out

reset onto merge -C 7fefa1b68e ds-branch-checked-out # Merge branch 'ds/branch-checked-out' into ds/rebase-update-ref pick a0bfa0ec53 t2407: test bisect and rebase as black-boxes pick 43547f7a52 t2407: test branches currently using apply backend ... pick 8b2a776cab sequencer: notify user of --update-refs activity ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----

So it would likely involve

 - "git checkout Q && git rebase -i --rebase-merge master" to get
   the todo list.

 - remove all "pick"s for existing commits on branch P, and replace
   them with a "break"

 - add an update-ref insn to update ds/branch-checked-out topic
   using the ds-branch-checked-out label at the end of the todo
   list.

 - exit the editor, and in the "break" session, run "am" to accept
   the new round of patches for P.

 - "git rebase --continue" to let the tip labeled as P and let the
   rest of the todo list rebuild Q

but I am not sure what should happen when there are more than one dependent topic (i.e. in addition to Q, topic R also depends on P). It also is unclear in the above procedure with "rebase-merge" what to feed to "range-diff" in the sanity-checking step. I could type "git range-diff P..." but being able to use @{-1} is a lot handier.