Some will say that it's a "red flag", others will say that those saying it's a red flag lack the experience of working on diverse set of projects with various needs and requirements.

Take Linux: they've got a "super-long-term-support" branch, a "long-term-support" branch, a "stable" branch, and the next "stable" branch. Stable is supported until the release of the next "stable" & 3 months after that, with (usually) 2-6 months between stable releases. "long-term-support" branches are supported for about 5 years, "super-long-term-support" for a few years after that. So there can be up to 4 released branches actively supported at any given time, ignoring any feature branches.

Not all software is developed by one software organization.

Programs to manage “stacks of patches” go back decades. That might be hundreds that have accumulated over years which are all rebased on the upstream repository. The upstream repository might be someone you barely know, or someone you haven’t managed to get a response from. But you have your changes in your fork and you need to maintain it yourself until upstream accepts it (if they ever call back).

I’m pretty sure that the Git For Windows project is managed as patches on top of Git. And I’ve seen the maintainer post patches to the Git mailing list saying something like, okay we’ve been using this for months now and I think it’s time that it is incorporated in Git.[1]

I’ve seen patches posted to the Git mailing list where they talk about how this new thing (like a command) was originally developed by someone on GitHub (say) but now someone on GitLab (say) took it over and wants to upstream it. Maybe years after it was started.

Almost all changes to the Git project need to incubate for a week in an integration branch called `next` before it is merged to `master`.[1] Beyond slow testing for Git project itself, this means that downstream projects can use `next` in their automated testing to catch regressions before they hit `master`.

† 1: Which is kind of a like a “megamerge”

It depends. We have pretty good review culture (usually same day rarely more than 24H), but some changes may need multiple rounds of review or might be have flaky tests that uncovers after a few hours. Also some work is experimental and not ready for pushing out for review. Sometimes I create a very large number of commits as part of a migration DND I can't get them all reviewed in parallel. It can be a lot of things. Maybe it happens more with monorepos.

I'd really like to hear your argument about when single large PR is better than stacked PRs from both PR author and reviewers' perspectives

Why would you like git and not jj is beyond me, this must be something like two electric charges being the same and repelling themselves. It’s the same underlying data structure with a bit different axioms (conflicts allowed to be committed vs not; working tree is a commit vs isn’t).

Turns out these two differences combined with tracking change identity over multiple snapshots (git shas) allow for ergonomic workflows which were possible in git, just very cumbersome. The workflows that git makes easy jj also keeps easy. You can stop yelling at clouds and sleep soundly knowing that there is a tool to reach for when you need it and you’ll know when you need it.

> you don't have a culture where

Yeah, and? Not everyone is in control of the culture of the organization they work in. I suspect most people are not. Is everyone on HN CEOs and CTOs?

I think the unspoken part is that the mess of commits is being produced by agents not people.

That’s why it’s always the same confusing hype when it’s discussed, because it’s AI/LLM hype effectively

Even if you're working on one single thread of development, jj is easier and more flexible than git though. That it works better for super complicated workflows is just a bonus.

jj reduces mental overhead by mapping far more cleanly and intuitively to the way people tend to work.

This is a little weird at first when you’ve been used to a decade and a half of contorting your mental model to fit git. But it genuinely is one of those tools that’s both easier and more powerful. The entire reason people are looking at these new workflows is because jj makes things so much easier and more straightforward that we can explore new workflows that remove or reduce the complexity of things that just weren’t even remotely plausible in git.

A huge one for me: successive PRs that roll out some thing to dev/staging/prod. You can do the work all at once, split it into three commits that progressively roll out, and make a PR for each. This doesn’t sound impressive until you have to fix something in the dev PR. In git, this would be a massive pain in the ass. In jj, it’s basically a no-op. You fix dev, and everything downstream is updated to include the fix automatically. It’s nearly zero effort.

Another is when you are working on a feature and in doing so need to add a capability to somewhere else and fix two bugs in other places. You could just do all of this in one PR, but now the whole thing has to b reviewed as a larger package. With jj, it’s trivial to pull out the three separate changes into three branches, continue your work on a merge of those three branches, and open PRs for each separate change. When two of them merge cleanly and another needs further changes, you just do it and there’s zero friction from the tool. Meanwhile just the thought of this in git gives me anxiety. It reduces my mental overhead, my effort, and gives overburdened coworkers bite-sized PRs that can be reviewed in seconds instead of a bigger one that needs time set aside. And I don’t ever end up in a situation where I need to stop working on the thing I am trying to do because my team hasn’t had the bandwidth to review and merge my PRs. I’ve been dozens of commits and several stacked branches ahead of what’s been merged and it doesn’t even slightly matter.

"Merge 2 branches" is already far from being a primitive. A git repository is just a graph of snapshots of some files and directories that can be manipulated in various ways, and git itself is a bunch of tools to manipulate that graph, sometimes directly (plumbing) and sometimes in an opinionated way (porcelain). Merging is nothing but creating a node (commit) that has more than one parent (not necessarily two) combined with a pluggable tool that helps you reconcile the contents of these parents (which does not actually have to be used at all as the result does not have to be related to any of the parents).

(you may know that already, but maybe someone who reads this will find this helpful for forming a good mental model, as so many people lack one despite of working with git daily)

It's easy to forget that what's "simple" is a function of what tools we have. And our familiarity with them.

I tried Sapling (Facebook's fork of mercurial with more polished git-compatibility layers) and never looked back for any of my own projects.

I recently started a new job where the vanilla git CLI is the only git frontend installed on company servers, and the regressions in user-experience are painful :(

Some did, sure. I made a more limited claim: you can convert back and forth between mercurial and git.

But in general you are one of the few that does. Many devs do find git rebases scary. Having done it in both I can say with JJ it is much much simpler (especially with jjui).

> I've been doing this in git for years.

You've missed a crucial detail.

You've both been doing it, but only one of you was using a tool that needed rebases to pull it off.

no ignore the tools mentioned the page is just a timeless summary of the workflow

I've often found myself needing to work on two features at once, esp. where one has a dependency on the other. Maybe that branch is the real goal, and the other branch is an independent chunk of work that the feature needs.

Both get iterated on, because it's hard to know everything about a feature before it's done; maybe you find bugs that need fixing, or you realise you were missing something.

Rebasing the dependent branch onto the tip of the other branch gets you there, but as a workflow it's not pleasant, especially if you're not the only person working on the features... It's a recipe for conflicts, and worse that rebased branch conflicting with another person's view of it.

Another example is that there is this simple monorepo that holds both the latest _BlaJS_ frontend and the backend API.

You are working on stuff in the backend, but it sure would be nice to see it in the frontend so you jury rig something in the frontend to display your work as well as some console.log() commands. Then you forget to revert changes to the frontend before pushing the branch.

In jj you would start with these as separate branches. Then you work on a merge of these. Then you use the absorb command to auto-move the code you are working on to the correct branch or you squash the changed files to the branch. Then you can push the backend branch to server and PR it. Then you throw away the frontend branch or just leave it there so you can use it in a future feature.

A real case from my work. I had to work on an old Python project that used Poetry and some other stuff that was just not working correctly on my computer. I did not want to toucj the CD/CI pipeline by switching fully to uv. But I created a special uv branch that moved my local setup to uv. Then went back up the tree to main and created a feature branch from there. Merged them together and worked out from that branch moving all the real changes to the feature branch. Now whenever I enter that project I have this uv branch that I can merge in with all the feature branches to work on them.

Imagine you have 3 branches: local-dev-tuneup, bugfix-a, feature-b

Remember in JJ you're always "in a commit", so the equivalent of the git working tree (i.e. unstaged changes in git) is just a new commit, often with no description set yet. (Because in JJ a commit also doesn't need a description/commit message immediately).

So in a mega-merge you can have a working tree that pulls from local-dev-tuneup, bugfix-a, and feature-b, and you can then squash or split changes out of it onto any of those source branches. Like you can avoid serializing those branches before you're ready to.

I've definitely faced the scenario in Git where I have a unmerged changes that I want to use while continuing work on a feature branch. I end up creating a PR for the branch of the first smaller features (e.g. local-dev-tuneup->master), then a second PR pointing at the first (feature-a -> local-dev-tuneup). It works but it's all a bit cumbersome, even more so if feature-a ends up needing to land before local-dev-tuneup. JJ has better tools for handling this.

Or potentially a team member has critical changes with a PR open and you want to start building on top of their changes now. Manageable in Git but you're locked in on a branch of their branch. Now add a second set of critical changes. Can be done in git but you'll be jumping through hoops to make it happen.

Of course you might say that all indicates a workflow/process problem, but my experience is this situations are common enough but not frequent.

(I haven't actually used megamerges myself yet but the article has me ready to try them out!)

eh, there have been a good amount of breaking changes. `-d`/`--destination` → `-o`/`--onto` (the former isn't yet deprecated though); deprecated `--allow-new` on push (or, forcibly making it the default for `--bookmark`); deprecated `jj bookmark track foo@bar` (and `jj bookmark track foo` having a really-weird system (I personally just call it broken, even though the behavior is intentional) of sometimes tracking the bookmark on all remotes; really I'd call jj's entire system of bookmark tracking/pulling/pushing quite incomplete outside of the trivial cases); various changed revset functions over time that break configs; and a really-annoying thing of `jj git fetch` sometimes abandoning ascendants of `@` leaving you in a confusing state (if not one with conflicts), with the solution being a future `jj git sync`.

It's certainly very usable despite all that, and the changes are simple enough to adapt to, but it's a pretty new thing.

> The unit of work is no longer “branches” or “commits,”

It better be, now and going forward for people who use LLMs..because they will need it when LLM messes up and have to figure out, manually, how to resolve.

You ll need all the help (not to mention luck) you need then..

A lot of words to say "LLMs are good for this, trust me bro!"

You're bashing the old way, but you do not provide any concrete evidence for any of your points.

> The unit of work is no longer “branches” or “commits,” it’s intent.

Insert <astronaut meme "always has been">.

Branching is always about "I want to try to implement this thing, but I also want to quickly go back to the main task/canonical version". Committing is about I want to store this version in time with a description of the changes I made since the last commit. So both are an expression and a record of intent.

> Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state.

Your choice of words is making me believe that you have a poor understanding of version control and only see it as storage of code.

Commits are notes that annotates changes, when you want to share your work, you share the changes since the last version everyone knows about alongside the notes that (should) explain those changes. But just like you take time to organize and edit your working notes for a final piece, rebasing is how you edit commits to have a cleaner history. Merging is when you want to keep the history of two branches.

Conflict resolution is a nice signal that the intent of a section of code may differ (eg. one wants blue, the other wants red). Having no conflict is not a guarantee that the code works (one reduces the size of the container, while the other increase the flow of the pipe, both wanted to speed up filling the container). So you have to inspect the code and run test afterwards.

Discard the above if you just don't care about the code that you're writing.

There are a lot of assumptions baked into your assessment. We are not at the point where manual workflows are obsolete. Maybe it is for folks who work on web apps, but it's certainly not the case for many others. AI Agents are constantly making mistakes and need oversight. Things have gotten dramatically better, but not enough for me to trust it to not create a terrible mess.

No, I don't trust AI to do much of anything. I've written in other comments on HN that I mostly use it to write draft commit messages and pull requests that I review and rewrite myself, now that the honeymoon phase has ended. But when I was still attempting to get it to do more, I found Claude Code was really bad at trying to fix conflicted merges and rebases, always dropping the wrong parts of the code and leaving me with a broken codebase and a commit message history that didn't make sense for the changes inside.

If you have a dependency tree like this:

       / A \
      -- B - Megamerge 
       \ C /

There is nothing stopping you from doing this:

       / A - D \
      -- B ----- - Megamerge 
       \ C - E /

(Edit, or even this:)

       / A - D \
      -- B ----- - Megamerge 
       \ C ----/
          \ E /

Where E stacks on C and D stacks atop A. In the case above, A-E are revsets of either 1 or more commits. JJ doesn't care if they are or not. You'd generally bookmark the revset on the final "commit" as the pointer.

           / features/add-widgets
          /  / features/add-widget-integration
       / A - D \
      -- B ----- - Megamerge 
       \ C - E /
          \   \ feature/add-new-page
           \ feature/rework-navigation

In the example above, let's say you rework the navigation. You could have it exist alongside the navigation rework, but changes are you don't want to do the work twice. You just say "hey, this depends on the nav rework" and so it's there inside of the repo.

The thing is there is another way to do this where you end up with 4 different parents in a megamerge and your nav rework touches the megamerge and your new page is yet another revset is just a fork off of it. But yeah... JJ gives you a lot of flexibility in this manner.