Thread (2 messages) 2 messages, 2 authors, 2022-07-16

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

From: Junio C Hamano <hidden>
Date: 2022-07-14 18:12:06

Derrick Stolee [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help