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.
I use AI prolifically for coding, but I haven't crossed the chasm of letting it do mutable operations on my vcs. It tends to revert changes too eagerly. Commit messages written by it usually miss the point of the commit and end up too verbose and need to be modified or completely rewritten in many cases. I feel like prose needs to capture style which is unique per individual which makes it difficult to do well.
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].
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.
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.
Very often when writing a new feature, I have to fix a bug in another subsystem (and write tests for it), add a small capability to another subsystem, fix documentation elsewhere, and so on.
Those could be separate commits in one PR, and that’s the way I’ve historically worked. But in jj it’s trivial to make them separate branches and continue working on the merge of all of them, even if they haven’t been merged upstream yet.
The benefit is that my coworkers have absolutely trivial PRs to review, rather than one omnibus. If there’s some debate about one of them, not only can we still make progress by merging the others, but I can continue plugging away on my main feature branch while we decide on the best path forward. If one of those PRs needed a bugfix or changes, fixing them typically m requires quite literally zero VCS shuffling to incorporate into the work downstream.
My pace of and ability to work on features is no longer bottlenecked by reviews. My coworkers no longer have to review giant PRs that touch seven subsystems. I don’t have to wait until an entire feature is finished before coworkers can start merging smaller preparatory bits for it.
You can do some of this stuff in git. But it’s excruciating and so nobody does it except in rare circumstances.
It's useful for low velocity teams that spend too much time in review.
For everyone else it's a net loss.
I've used Gerrit years ago, I thought it was great being able to shape my diffs into stacked chunks that reviewers could effortlessly navigate in a coherent story I'm telling.
Then I joined a company that wanted you to build and ship it in the same day. Now I dread the idea of going back to week long review cycles.
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.
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.)
Are we talking about the same git where—notoriously—one of the best ways to become proficient was to read Git From the Inside Out[1] replete with over 20 diagrams showing how various commands perform tree manipulations?
Gradle (instead of maven) or jj (instead of git) considered harmful. Fix your overengineering and stick with the basics. If you end up at a point where you are fighting with maven and git and need to reach for more tools, you already failed and should turn around.
Git is fine, just automate your workflow. I usually have 5-50 parallel branches which need to be rebased on every master/main update, and several branches are nested.
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
13 comments
[ 3.0 ms ] story [ 34.0 ms ] thread> 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.
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
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?
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.
Those could be separate commits in one PR, and that’s the way I’ve historically worked. But in jj it’s trivial to make them separate branches and continue working on the merge of all of them, even if they haven’t been merged upstream yet.
The benefit is that my coworkers have absolutely trivial PRs to review, rather than one omnibus. If there’s some debate about one of them, not only can we still make progress by merging the others, but I can continue plugging away on my main feature branch while we decide on the best path forward. If one of those PRs needed a bugfix or changes, fixing them typically m requires quite literally zero VCS shuffling to incorporate into the work downstream.
My pace of and ability to work on features is no longer bottlenecked by reviews. My coworkers no longer have to review giant PRs that touch seven subsystems. I don’t have to wait until an entire feature is finished before coworkers can start merging smaller preparatory bits for it.
You can do some of this stuff in git. But it’s excruciating and so nobody does it except in rare circumstances.
For everyone else it's a net loss.
I've used Gerrit years ago, I thought it was great being able to shape my diffs into stacked chunks that reviewers could effortlessly navigate in a coherent story I'm telling.
Then I joined a company that wanted you to build and ship it in the same day. Now I dread the idea of going back to week long review cycles.
Ick.
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.
[1] https://news.ycombinator.com/item?id=12802949
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