[karmakaze]

This has pretty pictures but its verbosity and frankly made-up complexity is making me not take it as seriously as I perhaps should.

The way I'd handle rebasing stacked PRs/branches is to rebase the very last one. Then simply `git branch -f a-branch <logical same point on rebased>` for each of the others, done.

I worked on a project that had weekly releases. We had git submodules, and submodules of that, and on rare occasions a 4th repo. I would manually keep those all up to date with rebases pinning each submodule to the logical new points. It all became muscle memory. The lesson I learned is don't use submodules unless you really need to. (All the repos were our own.)

JJ may be great but a stawman isn't going to sell it to me.

Now I can tell an AI to rebase a stack and as long as there weren't any conflicts easily check the results.

Everyone has things that bug them, git isn't one of mine (today :-). Instead I have a custom keyboard layout that no one else uses that makes me feel better, but I don't go around telling everyone they should switch--unless you're curious[0].

[0] https://github.com/qwickly-org/Qwickly

[porridgeraisin]

> Then simply `git branch -f a-branch <logical same point on rebased>` for each of the others, done.

Yep, and after 2022 you can do this with --update-refs.

Situation 1: main has moved ahead, pull it and move whole stack (say feat1..N) on top of that

  git switch main
  git tag old main
  git pull --rebase
  git rebase --onto main old featN --update-refs
  nvim app/config.py # fix conflicts if necessary
  git add $_
  git rebase --continue
  git push origin feat{1..N}

Situation 2: adding a commit based on PR review on feat1

  git switch feat1
  nvim app/models.py
  git add app/models.py
  git commit -m 'make username unique'
  git rebase feat{1,N} --update-refs
  git push origin feat{1..N}

replace N above with how many ever PRs you have stacked