How many PR's do y'all tend to have in flight at once? I sometimes think being a native (C++) developer makes me have a different take on some of this. Maybe if I was a JS dev making quick changes with 5 PR's a day I'd care more about this.

So I have a rb.sh script for every major project which does the (partially stacked) rebases. When my magit fixups didn't catch it. And of course a lb.sh script (alias for pull --rebase) for the other machines to import the updated branches

> Companies like Meta have enjoyed in-house systems that run circles around it for almost a decade.

Based on Mercurial… the VCS I enjoyed using.

Well yes because git was supposed to be completely distributed. You can design a system which has this feature but then it wouldn't be as distributed as git, making unrelated forks second class citizens. It might still be a good idea for tool to have it but it is not strictly a better/worse scenario.

> Mutability

I think i can mostly agree to this. I do wonder if people never work in a scenario where they are only committing partial state and not complete state. Nevertheless being able to track and not losing uncommitted state is a strict improvement.

> workflows

Aren't worktrees enough here?

Switching branches is not a solution, cause all of this changes develop at the same time.

Neither worktrees nor stashes are even nearby being a viable solution. Unless someone enlightens me and explains how to achieve this flow easily in git I’ll be looking for better solutions. I just installed jj and I do hope it will bring some relief.

To be fair, before working in monorepo I did not have this kind of issues, or at least not that annoying. And yes, LLMs made the issue even bigger, cause it happens more often that while I’m coding on main feature I’ll write to Codex: „btw, fix this one thing while I’m busy with main tasks”, so my workstream is actually more tree-shaped than stream shaped.

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