alt.hn

5/15/2026 at 5:51:09 PM

Git Is Not Fine

 https://www.billjings.com/posts/title/git-is-not-fine/

by steveklabnik

5/15/2026 at 11:56:36 PM

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.

by demorro

5/16/2026 at 5:48:42 PM

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.

by stouset

5/16/2026 at 8:37:52 PM

But that means you haven't actually done anything with the PR, it is a hypothetical thing.

Hopefully you have perfect CI coverage since you didn't bother to compile your PR even.

by Guvante

5/16/2026 at 11:21:00 PM

This flatly isn’t true.

Each individual PR gets tested and merged the same way they would if you’d authored them one by one in the first place.

The combination is merged in your tree well in advance of a PR ever being made. When the ancestor PRs are merged, you just pull and your descendent merge commit is rebased automatically.

At no point are you pushing untested code that you wouldn’t have pushed in a similar git workflow.

by stouset

5/17/2026 at 12:36:44 AM

I mean so it is identical to how I already do this...

If I am pushing a PR with a working combination and rebasing after upstream merges how is jj changing the flow?

by Guvante

5/16/2026 at 12:17:56 AM

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.

by lorecore

5/16/2026 at 5:34:49 AM

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.

by chadgpt3

5/16/2026 at 10:45:27 PM

You should be rebasing your PRs before you put them on main though. Test prior to doing that should not be expected to be repeatable.

by lorecore

5/16/2026 at 1:10:39 AM

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.

by squirrellous

5/16/2026 at 9:11:01 AM

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.

by ahepp

5/16/2026 at 1:29:17 AM

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.

by surajrmal

5/16/2026 at 9:24:47 AM

Do stacked PRs do something to avoid rebase conflicts if two people touched the same file?

by ahepp

5/16/2026 at 3:45:34 PM

No but it's a lot simpler to rebase and address them with stacked commits.

by surajrmal

5/16/2026 at 11:53:00 AM

I feel like parent was referring to a culture of shipping small changes frequently, which tends to result in stacked PRs.

by squirrellous

5/17/2026 at 6:53:56 AM

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.

Ick.

by bfivyvysj

5/16/2026 at 3:58:37 AM

[flagged]

by SupLockDef

5/16/2026 at 3:49:56 PM

If you like a thing, it feels natural to tell others about it so that they can also benefit from it. There is no ulterior motive here. Sure everyone in the community will benefit if jj becomes more popular, but it's not like they are trying to sell you something for money. If you don't like it, that's fine, but if someone is facing similar problems to the OP then they will benefit. Almost everyone I've shown jj to at work has converted because it solves the same problems for them as it did for myself. Of course, not everyone has those problems.

by surajrmal

5/16/2026 at 5:53:36 PM

> There is no ulterior motive here.

I just want to point out that it is known that one of the biggest jj proponents on HN does have financial incentive to do so.

Steve Klabnik (the person that submitted this post) comments and posts about jj here often and works for https://ersc.io (startup mentioned in the post).

So don't be so sure that all of the PR here comes from a pure selfless act. Some of them have income tied to the solution they are preaching.

by hu3

5/17/2026 at 6:33:28 PM

Sure, but I don't and nor do most of the jj community. esrc has less than 10 folks working on it, the number of jj enthusiasts is massive.

by surajrmal

5/15/2026 at 9:59:57 PM

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.

Based on Mercurial… the VCS I enjoyed using.

by vintagedave

5/16/2026 at 12:06:54 AM

There is an open source & git compatible version of Meta's VCS: https://sapling-scm.com/

by miguel_martin

5/16/2026 at 3:58:02 PM

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.

by surajrmal

5/16/2026 at 7:39:14 PM

I agree on the commit messages not being ideal, though a bit of by-hand rewording goes a long way.

Recently let Claude Code handle some commit history clean up: split a couple commits, reordered some, and identified some that could/should have been fixups, and reduced the number of commits from ~70 down to ~40. Very happy with the results and time savings.

FWIW, here’s my interactive rebase skill: https://github.com/cstrahan/claude-plugins/blob/main/skills/...

by cstrahan

5/16/2026 at 6:37:51 AM

IIUC, jj was heavily inspired by hg. In particular, the revsets and the UI.

by KingMob

5/15/2026 at 11:13:53 PM

> There is No C

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?

by alphabeta3r56

5/16/2026 at 6:57:23 PM

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

by rurban

5/16/2026 at 7:02:04 AM

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.

by luckymate

5/16/2026 at 8:04:20 AM

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.

by lemonwaterlime

5/16/2026 at 8:49:40 AM

Thanks! I’ll check it out

by luckymate

5/16/2026 at 9:21:47 AM

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?

by ahepp

5/16/2026 at 1:17:31 PM

Fair question.

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.

by luckymate

5/15/2026 at 10:04:58 PM

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

by karmakaze

5/16/2026 at 8:41:51 AM

> 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

by porridgeraisin

5/16/2026 at 5:01:10 PM

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.

by Traubenfuchs

5/15/2026 at 6:04:46 PM

[dead]

by Bret_McKinney

5/16/2026 at 11:47:38 AM

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.)

by applfanboysbgon

5/16/2026 at 6:00:15 PM

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?

[1] https://news.ycombinator.com/item?id=12802949

by stouset

5/16/2026 at 8:52:12 PM

What do you want from me? I literally specifically called that kind of thing out in my comment[1], which was four sentences long of which half were about Git, so I'm not really sure how you missed it. Even that article assumes you already know how to use Git[2], in other words the premise of that article is not teaching you how to use Git or convincing you to use Git, but rather expanding knowledge you already have (and in reality probably don't need).

[1] "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."

[2] "It assumes you understand Git well enough to use it to version control your projects."

by applfanboysbgon

5/16/2026 at 11:13:46 PM

That isn’t even about black magic wizardry. That tutorial covers adding files, committing, switching branches, and merging: in other words, the absolute basics. It was, and maybe still is, one of the best beginner resources on how to make sense of the git CLI for people who are confused.

And it required at least twenty diagrams.

What do I want from you? Maybe a little less high-and-mighty a tone when dismissing a tool for being so complicated someone decided to use diagrams to explain it, when the very thing being replaced is so complicated that one of the best beginner resources needed to use diagrams to explain it.

by stouset

5/16/2026 at 11:33:22 PM

You certainly do not need 20 diagrams to learn the basics of Git. If I had to consume the article you linked to start using Git, I would not have been convinced to. The article itself states that it assumes readers already know how to use it, so if that's what beginners are being pointed to, I think that's a crime against pedagogy.

by applfanboysbgon

5/17/2026 at 5:37:21 AM

You certainly don’t need 20 diagrams to understand why you’d want to use jj. This author happened to think it would be useful. Apparently pictures of data structures are crimes.

Meanwhile, that article is inarguably the thing that made git “click” for an enormous number of people regardless of your disapproval of how some people prefer to learn.

Maybe be less judgmental.

by stouset

5/17/2026 at 7:16:50 AM

> You certainly don’t need 20 diagrams to understand why you’d want to use jj.

You're talking about Git and jj. Surely, then, you must be a programmer, or at the very least have a passing understanding of programming. Perhaps you would like a refresher on control flow?

"If it takes 20 diagrams to make your case for why jj is better... Git is fine"

  if (jjArticle.Diagrams.Count >= 20) Git = Fine;
  else if (jjArticle.Case == Compelling) Git = NotFine;
  else Git = Fine;
I made an if statement. If the condition of my if statement isn't true, then a different branch is followed.

The article is extremely presumptuous, asserting that the software the reader currently uses is not good enough. I find the article strongly fails to make that case, and a part of why is because anything that takes 20 diagrams to explain is more convoluted than I need, ergo, Git is fine. That doesn't mean jj isn't good. Maybe jj is even better than Git. But the premise of the article isn't convincing the reader that jj is better than Git, but rather than Git is not good enough and that the reader should explicitly go out of their way to stop using it in favour of jj, which is a much stronger case to have to argue. You suggested I'm being judgmental but if anything it is the article that is judgmental.

by applfanboysbgon