I consider myself a shmedium experienced dev who likes to learn their tools and read source.

This seems like a house of cards whose juice isn’t worth the squeeze. But I would love to split up my PRs into smaller pieces.

I just would hate to waste time with an incomprehensibly goofed git history because I forgot a command.

I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.

I'm a heavy user of git-spice: https://abhinav.github.io/git-spice (created by a former coworker) and can't really go back to a time without it. While still not nearly as good as Facebook's Phabricator, it's probably the best workflow for small, focused stacked PRs you can achieve in a Github / Gitlab based repository.

I think ‘git rebase —-update-refs’ is the better way to go for this scenario

Jujutsu comes in handy here for the same usecase:

https://github.com/jj-vcs/jj

https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut...

Also found https://github.com/gitbutlerapp/gitbutler

This marker branch step feels like a workaround to a missing capability. It's something I can easily see one forgetting especially if they haven't been doing stacked diff workflows regularly.

That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.

GitButler handles all of this pretty automatically, if you don't want to deal with the Git gymnastics needed here.

https://blog.gitbutler.com/stacked-branches-with-gitbutler

I believe the author would love stg: https://stacked-git.github.io/guides/tutorial/#patches