I continue not to understand much of the point of this. I don't recognize the git workflow the author is talking about, and neither do I see the point of stacked PRs. Commits are fine as a unit of isolating work, and rebasing to keep that neat is not difficult.
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.
I totally agree. I've never understood the push back against clean "railroad tracks" (i.e. rebasing instead of merge commits). It's simple, scales nicely and gives you a lot of options. Once you start allowing merge commits in the tree, things can get messy but with a bit of discipline, it elegantly solves every version control use-case I can think of, or have encountered, including at scale.
If you have a large PR with multiple nontrivial commits I think you should merge it so the intermediate states are the same ones that were originally tested. Otherwise you could break bisects, among other issues.
I work primarily in c++ and fully agree with the author. I think it makes more sense in the context of larger teams, possibly also monorepos. Review speed (both latency of feedback and how thorough your reviewers are), presubmit test runtime, flake rate, etc can lead to it taking a few days to get work submitted. In some cases you don't want to land work until you've finished a milestone of some sort. If others work on similar files to you, you will end up with several rounds of rebase conflicts to deal with too.
Stacked PRs is mostly a way to avoid thousand- or tens-of-thousands- LOC branches, which makes each PR meaningfully reviewable. You need a good code review process for it to become useful. It’s very pleasant once you are accustomed to it.
I’ve seen successful teams that regularly do reviews of massive PRs and feel this serves them well enough. I suspect it just places a lot more trust on the developers to get the details right so reviewers only look at larger design issues.
The language of choice is not relevant. Even before AI, one can accumulate thousands of lines of c++ easily.
I've also seen teams struggling to review massive PRs as a single diff, but when I've seen that it's always because they aren't structuring commits to be individually reviewable.
I admit the diagrams and struggles the author describes are far past my own usage of git. And like they identify at the end of the article, for truly complex git operations today I use AI. I haven’t rebased manually for a while. Forget rewriting commit messages!
> Companies like Meta have enjoyed in-house systems that run circles around it for almost a decade.
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.
Working in growing monorepo I find git tragically annoying and lacking. On regular basis I stumble upon situations where I work on one thing, but it causes changes in other package and I have no clear no way to say: this changes go to branch #1, this other set of changes to branch #2, and another small fix to branch #3. Branch #1 depends on the others and once #2 and #3 get merged it should merge to master cleanly with no ceremony.
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.
You should look into `update-refs` functionality. By default git treats each branch independently, but with update-refs, git tracks pointers to branches and creates a dependency chain.
I don't mean to suggest you're doing something wrong, but it's not clear to me why you need three separate branches for this? Why not have these related changes as individual commits on a single branch?
First: even though the logic is connected the work happens in different packages, with different test suites and logically it’s seperate. I want the ability to traverse history of each feature separately even though they’re connected and I develop them at the same time. So package #1 has moved forward but I actually changed my mind about API for package #2 and want to roll it back. If all work happened on one branch I don’t see a simple way to do it, without rewriting history and cherry picking particular changes.
Secondly: I want to push changes separately for ease of review. Big PRs wait longer for reviews and the longer they wait the more conflicts I can get because something else has been merged while I was waiting for review.
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].
> 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
If it takes 20 diagrams (I counted!) to make your case for why jj is better... Git is fine. I don't need software that takes 20 diagrams to convey why I should consider it. (That includes a lot of the black magic Git wizardry too, of course. The extent of my Git usage does not require anywhere near 20 diagrams to explain either.)
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.
reply