On Tue, Nov 01, 2022 at 03:23:25PM -0700, Junio C Hamano wrote: > and use > > $ git branch --no-merged jch --no-merged seen --sort=-committerdate '??/*' > > to see any topics that are not in last 'seen' and 'jch' we just > rebuilt. They are either replaced in 'seen' or new ones. Then > merge some of them that you are more confident than others to 'jch' > and test and update the redo-jch.sh script. > > $ git merge xy/xxy > $ git merge fr/otz > ... > $ Meta/round ;# or whatever tests that are appropriate > $ Meta/redo-jch.sh -u > > This "-u"pdate step can be done without disturbing what should later > build on top for 'seen' by having the script separately. Ah, OK, this is the part I was missing. I assumed you would write the new topic names into the redo-jch file, then run it to create the merged state (since with rerere, it's easy-ish to reset jch back to master and just rebuild to the desired spot). But that is inside-out from your workflow, which is to treat topics individually. Updating redo-jch.sh is done by the script and explains what you did manually, rather than manually updating redo-jch.sh and having it build automatically. Your way makes much more sense, since you get the opportunity to examine the intermediate states more closely. Thanks for explaining! -Peff
