> version control systems must be shared.

This whole thread is about working with git coworkers while using jujutsu, and it was in that context that I wrote my comment: Namely that most who prefer jujutsu happily work with their colleagues who use git in precisely the scenario the OP mentions and don't see why the OP finds it painful. The OP and others should accept that reality.

> If it is like you say and different people are just inherently more or less suited to different paradigms, then not everyone can be happy.

If you force everyone to use git, of course not everyone will be happy.

If you force everyone to use jj, of course not everyone will be happy.

Thankfully, the whole point is git and jj users can interoperate without needing to care what the other is using. So yes, not only can everyone be happy, but everyone is happy! This isn't a hypothetical - it's a reality. It's the reason so many use jujutsu at work.

> I think I said named branches, but that is definitely what I mean

I think I misread you, because you were talking about git vs svn in a way that made it sound like jj was a step backward from git as regards branching, and I got confused.

> I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.

Right, but you can still name your branches with bookmarks, you’re just not required to. Personally, I tend to use commit descriptions more than bookmarks to keep track of what I’m working on, but this is a personal choice.

> Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?

It’s just nicer as a local workflow, to me at least? I can create throwaway branches without having to come up with a name for them. I end up creating many, many more branches than I did in git as a result, which helps me keep my work better organized and my changes more focused when I submit them for others to review (which at least on GitHub, requires a bookmark of course). This is ultimately psychological because obviously I could just make up a name for the git branch, right? But it makes a big difference for me!

> it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.

Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.

The biggest issue is my git knowledge is atrophying while my coworkers still know me as “the git wrangler” (mostly because most devs have never actually learned git, so any knowledge looks 10x more than theirs). So when a coworker comes to me with a problem like their local main now has 2000 commits that they’ve (or rather Claude Code has…) somehow accidentally re-signed locally and then the 20 commits that actually contain their work, I’m thinking this would be easy to fix with jj rebase but the best advice I can give them for git is to reset their local main to origin/main, create a new branch and then cherry pick their 20 commits to their new branch. Since that’s too time consuming they just checked out the repo again and copied their working copy over, which is the level of avoiding actually using git that the git CLI routinely inspires.

Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.

Yes, that describes me at both jobs I’ve had since learning jj. Hence why I asked for specifics: I’m genuinely curious what other people struggle with, partially because I’d like to help them if I can, and partially because it gives me a better understanding of common pitfalls which helps when teaching other people.

Yes, that is the case for almost every repo I’ve ever used jj for. It is a complete non-issue. There is virtually zero friction.

yeah nobody "has to know", especially if everyone else is also rebasing etc constantly.

I do this all the time at my job, without issue. I think it's honestly easier than using plain git.

I believe this is the most common scenario, yes. If you're used to actively pushing and pulling from the same branche as your colleagues, you need to learn how to manipulate diverging changes and conflicting bookmarks, but other than that all the jj magic is limited to your local activity.

I use jj all the time for pull requests, in fact I don't use regular git at all anymore, and it's perfectly easy. Not only can I easily keep all my pull requests properly synced to their base branches, but I can easily and very quickly address review comments, keeping the commit stack clean without having to manually squash or amend or anything of that sort. Honestly it's a lot easier and more efficient than git for me because of how much naturally follows rather than requiring explicit imperative fixups.

Of all the things I was imagining it might be, this was down at the bottom.

Personally I’m a huge fan of this approach. If you aren’t, it’s literally just a one-liner (that is trivially made into an alias) to advance a branch name to the most recent revision. And now there’s a feature to do auto-advancing if you want it.

Why is it this way? Because jj is designed around revisions being constantly mutated.

In git, when I make a commit, I am typically signaling that that a chunk of work is complete. Not always, but usually. In most jj workflows, revisions are mutated constantly during development. A revision being made on the tip of a branch is rarely a signal that that unit of work is finished. It’s even incredibly common to have multiple revisions in a row that are works in progress. Hell, the article we’re all commenting on discusses just such a workflow. If I make five revisions on top of some branch, there is no reason to assume that any of them are ready to be shared, much less all of them.

Because of that difference, it makes sense to have an explicit act to move a branch name forward.

They added auto advance bookmarks a while ago. You configure which revset bookmarks you want to advance or not, and then it just keeps them at the "head" of a branch

> But you probably haven't spent time writing commit messages before a branch is finished.

Wrong. With jj, I use `jj describe` before I start work. It is like writing out a plan for what I want to do.

> Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change.

Rewriting it is not wasted time. It is an opportunity to look at what I have written in the plan and check whether I have really executed them, and then rephrase things to be more easily understandable.

> Restricted and summarized is good - easier to find/remember, less fluff in a list.

The first line of a commit message is already a summary of the work done. And you can use actual English instead of trying to awkwardly avoid spaces in your words.

When its MR time I use jj push -c and I’ve set my config to auto generate a branch name from the commit message by extracting the ticket ID from the commit message since we have a standard format into something like PROJ-1234-nzytopmn . Since the company I work at enforces squash merge since many coworkers would otherwise have 20 merge, fixup, lint or ci fix commits per MR, auto advancing isn’t relevant. Addressing comments is just squash into that change and repush. We don’t really do long lived branches so the ticket number is enough to find the branch and the commit message explains the change if I need to hand over work.

I collaborate a whole lot. In fact for solo development I use git because jj is overkill for it. Also by default jj prevents you from overwriting commits that exists on the main branch on the remote, but this is what I often do on solo projects.

> having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters

In my view, all the above information exists not in the branch name, but either in the ticket, or in the commit message. The branch name is purely a superfluous thing that does not convey any information. Many of my colleagues already use a tool to automatically name their branches from the first line of their commit messages, and jj just makes this awkward process straightforward.

Using jj is easier when your whole team uses jj. When the rest of your team uses Git, it's understandable that the pains of keeping up with Git-isms (e.g. constantly updating branches) start to become quite inconvenient. Though once you get used to jj they're not much of an inconvenience at all, they are still extra steps compared to raw Git. So if jj doesn't have any other inherent value to you it makes sense not to make the jump.

To me, jj has inherent value because I do a lot of things raw Git makes difficult or impossible. For example, https://github.com/LoganDark/fabric-template supports every point release of Minecraft since 1.14, and mods like https://github.com/LoganDark/debrand derive from it. I often rewrite the history of the template with configuration improvements and then rebase the histories of each mod on top of it.

This keeps my project setup consistent throughout versions, and consistent between mods, and allows all my mods, across all supported versions, to benefit trivially from all improvements I make to my global template. This workflow is either not possible with git or would require slow, ugly and fragile scripts.

I'm excited for your delayed comment. I'm sure going to take note that you delayed it and come back later to read it because I'm super interested in what it is that you've delayed. You know, you can just write the comment instead of holding your place in line

You can literally jump into a commit and edit its contents directly, and everything is auto-rebased on top.

There are no modal “sorry rebase failed, best of luck” gotchas. There are no “oops I put the wrong thing in the wrong part of the rebase and now I have to abort and start all over” gotchas.

It’s rebase, but without all the extra work, mental overhead, failure cases, and effort.

Culture change is hard.

A lot of humans still don't use git too.

Many do only when they are forced.

And it's much easier for a professional to be forced to use LLMs than jj when it comes to versioning assist (not even comparable in mindshare but the obvious needs to be said sometimes).

So unfortunately I'm afraid jj is not going to achieve critical mass before 99.99% of merges are done by AI which don't need jj.

It's interesting that even clear advantages like `jj undo` are hard to communicate because of this.

> I spoke about this before, but jj has the Blub Paradox problem

It's not relevant. Don't try to convert git users--you don't need to. They're fine doing what they do, and the git backend store is acceptable. People who understand how broken git is will gravitate to jj with the lightest of prodding--give them a light poke and then don't harass them further.

The main difference is that I can teach jj (like I could teach hg) to normal people. And, because jj is based on the git store, they can operate in a Github world.

So, just teach jj to people who haven't yet broken their brain with git. Running on the git backend already gains most of the network effect, so don't proselytize the git people.

The problem with this mindset, that there is zero reason to move away from Git. I can do effortlessly everything with it. There is no incentive. I never said "it would be so good that I would be able to X"... and I didn't find a solution for it quickly. As under this post is obvious as much as under other previous posts, you can do the same things effortlessly with Git. The effort is not that I need to use 2 commands less, but to separate the code (in this specific case), which takes about a 100-1000x more time than typing those 2 extra commands, or really the need to think what kind of commands need to be used in any VCS.

The same problem with vi for example. Which I learned, deeply and for a long time. Maybe I will be break even in a decade or two. And for example, I can code faster than anybody who I know and use vi all the time (or some vi keyset in Emacs or something), not because I type faster, but because I don't need to rewrite my code that many times than them.

The same with jj. I'm happy that it clicks better than Git for some. But I know Git from inside and out. Git was never the bottleneck for me. And really any VCS in the past. If I learn jj, then I don't expect that the effort pays off in a decade or less in the best case. My work's result would be the exact same thing, just with different commands, commands which takes almost no time compared to my other tasks.

> Unfortunately, the only way to get it is to spend a week with it, with an open mind

We do get it. But have you ever thought that git inflexible nature and full control is what some people people like?

Having three different state for your work (working tree, staging, and committed) is nice for reviewing code. Picking lines and chunk give me an additional mental state to think about the design of the code.

And once upon a time, I preferred history log like the one in the article. But this days (mostly inspired by mailing list development style) I wants the commit in my main log to be either features or bug fixes. Everything else is “wip”, which I will squash. It makes it easier when rewriting history, cherry picking, or just browsing the log.