Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
> Before:
>
> A---B----C---M---Q1---Q2---Q3 <-- refs/heads/Q
> \ /
> P1--P2--P3 <-- refs/heads/P
>
> After rebasing both topics simultaneously (with 'git rebase --update-refs
> C' while Q is checked out):
>
> A---B---C---D---P1---P2---P3---Q1---Q2---Q3
> ^ ^
> refs/heads/P refs/heads/Q
>
> But it seems what you mean to say is to update the merge commit M, which
> means that the 'P' branch above has been updated independently of the 'Q'
> branch, so we need to update 'Q' after-the-fact.
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'm not sure what that rebase would look like, indepdendent of
> updating refs.
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.
