Hacker News Reader

Comment by palata | Hacker News Reader

> For anyone who's debating whether or not jj is worth learning

I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day.

I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere.

To me it sounds like telling me: "You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff. But you will be infinitely more productive: when you start bim, you're already in edit mode, so you don't have to type i! And the auto-complete in Julia is objectively a lot better in bim!".

Sure, but typing "i" a few times more is really not a concern for me, and I don't use Julia. But if it's better for you, please enjoy bim!

View on HN

For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important.

This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently. I greatly prefer working with (and being) the kind of developer that puts out a large number of very tiny and easy to review PRs, eve. jj makes doing that a breeze.

There are lots of people for whom these things aren't important. I will be slightly judgmental and say I don't really enjoy working with them. They tend to write very large PRs that are difficult and time-consuming to review. And it's a frequent source of frustration for everyone when 95% of the work is uncontroversial but a merge is being held up because of legitimate concerns with an unrelated 5%. This is even worse when there's later work that builds upon it that can't happen until a merge (or that needs to be constantly rebased as the PR is improved).

This is not to say if you do this you’re a bad developer. There are plenty of great developers who don’t care about these things and still do great work. This is also not to say you can’t follow my preferred approach with git. I did it with git for a decade and a half.

Wow, that does sound like a big improvement. My git commits are, when not forced to be otherwise, very sloppy, even though I’d prefer them to be neatly self contained. But as you imply, there is friction to making these in git, while making lots of unrelated changes in a single coding session.

As an example of another ‘unnecessary’ switch, Pip with venvs was also completely solving all my Python dependency problems. I just needed to copy paste a few lines from my README to create and populate the venv, and remember to run pip and Python from that venv. And run pip freeze after package installs or upgrades. No problem. But switching to uv was a huge life improvement. No more copy pasting (‘uv sync’ does everything and even that isn’t needed) nor remembering extra steps and everything is fast so I’m never waiting and forgetting what I was going to do.

I could’ve been GP talking about pip but still I would be missing out.

I still see people clinging to cvs because it works for them (netbsd why?), which I respect but don’t understand/believe.

Fish don’t know what water is.

So.. I’m gonna give jj a go and trust life will be better again.

I'm fairly confident you're going to love it. I'd read a few tutorials, but what finally clicked for me was just asking Claude what commands to use, and then explaining why.

Jujutsu finally made me understand git, after ten years of git use. It removes enough of the magic that I now know exactly what the commands do, and how the data model works.

You'll love jj, as you've already been able to see the the light with new tooling like uv.

Jj is to git what uv is to other python tooling.

Check out jjui as well, which makes jj even better. https://github.com/idursun/jjui

https://mise.jdx.dev is equally as revelatory as jj and uv

mise is awesome. Put it off far too long after a bad first experience. Now I'll never go back to asdf

Mise really is awesome. We are coming into a new golden era of tooling and I want everyone to experience these things.

IMO this is all being driven by Rust. jj, mise, ripgrep, fd, bat, eza, delta… all of the best of breed tools these days seem to be coming out of that ecosystem.

Mise just grew support for GitHub, gitlab, and arbitrary http as sources for tools. The ubi integration previously covered much of this, but had blind spots for things that were "bigger" than just a single binary

I tend to `git add -p` and create different commits that I put on different branches if they are unrelated.

Doesn't feel painful in git, but I'd like to see an example doing that with jj. Maybe I'll try.

jj lets you do this with changes that are related.

I can do it with changes that are related. But I understand that jj makes it trivial, which is not a life-changer but it's nice. Does that sound about right?

Nice commits can really tell a development story that makes reviews easier. That said, I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release.

A very, very large problem at five out of six companies I have worked at is casual code improvement and refactoring. Devs would say, "we will address that minor and unrelated thing in a separate PR" - one that never comes. At one company, a single PR could address unrelated fixes and it was encouraged to "take out the trash" on the code. Unrelated metrics added, logging improvement, or code simplified, or test robustness improved, etc. That company had vastly better code. Easier to read. Easier to maintain. Easier to observe. And easier to test.

> That company had vastly better code.

It's very frustrating that what IMO is the inferior approach was producing better results in those teams!

It's because what you see as the inferior approach involves less effort and friction for the developers.

When you are told to separate general code improvements to another PR, or worse, to not do them, and create a Jira task for them so they can be adequately prioritized, it just saps your will to do so. You just won't do any improvements that fall outside the scope of the feature, because even just thinking about the hoops you have to jump through to get work done is mentally draining.

I don't know how but we need to get developers out of thinking of PRs as the smallest possible change unit. This is literally what commits are for, you do a chunk of work, and you have a commit which describes that chunk of work. If you've got cleanly isolated commits then when you come to reviewing the PR (or changeset as I'd much rather see them called) and someone questions the wisdom of including that particular change you can either modify the commit to satisfy the questions, or just pull it out of the changeset into it's own for later review without blocking merge of the wider feature.

Coincidentally jj makes this process much easier than it would be with git, it will very happily let you shift commits around between different branches, edit commits in place and cleanly rebase those edits onto subsequent commits, or split a messy commit into two commits that makes sense.

The UI may be cluncky in the PR page, but I just use rebase, edit the commits, and force push the whole branch. The PR is the unit from the business perspective, not from my computer environment. I don’t mind creating two PRs for stacked changes, then once the first is merged, rebase from the main branch and publish the second one. Comments can be used to explain the link.

I think the confusion and angst comes from when someone has multiple unrelated commits, submits it as a single PR, and is then REVIEWED intermingled all at the same time!

If people instead reviewed commit by commit until the PR HEAD, the code itself would tell a story, but best of all - the story would then be obvious!

> It's because what you see as the inferior approach involves less effort and friction for the developers.

I can see that.

From the other side of the PR though, it involves significantly _more_ work from a reviewer.

The "red tape" of separating commits and opening separate PRs should be removed by the team.

The effort of separating commits and opening separate PRs is minimal once you're comfortable with the tools.

I encourage colleagues to be comfortable with these workflows, because a reviewer's time is generally no less valuable than their's.

Jj makes this effort vastly easier. Nearly frictionless.

Great. As I said elsewhere on this story, I'll suggest jj to colleagues who struggle with git.

Yeah, I don't get it. Maybe I'm just confused but the git mental model has never struck me as complex or confusing.

jujutsu also seems like a poor fit for large monorepos repos (particularly ones that use git hooks). The expense of certain git operations increases quadratically with the size of the repo. A repo doesn't need to be terribly large for `git status` to require 5-6 seconds. (God bless the man who added scalar and sparse checkout to git.)

The absolute last thing I want is a tool that's doing more with git -- creating commits, branches, checking things out, rebasing, or doing anything that requires a git-status check.

Reviewers don't want to navigate 33 tiny PRS either.

The best way of getting changes is through is simply sitting down and talking with the reviewer. Most of these small PRS, splitting things, creating elaborate stacking systems are just technology hacks around a social/process problem. I've seen people make more of a mess trying to split pr's up where they are so fine grained its silly and actually had dependencies on commits they didn't realise they had which reviewers then had to resolve. Literally anything to avoid talking and working with people. People are trying to turn a tightly collaborative process and turn it into isolated single work units with no collaboration that just need a rubber stamp.

> Reviewers don't want to navigate 33 tiny PRS either.

As opposed to one 33-change PR? Yes, absolutely yes they do.

I probably don’t have time to review a giant PR like that. If I do, I feel guilty asking for fixed in one part when 31 of the changes are great. Why are we holding up all these improvements for one or two small concerns? We can merge and just fix those later. Except that never happens.

I probably have time to review eight one-liners. My other coworker has time for five. After lunch I can quickly check out another seven. Over the course of the day all 33 get reviewed and merged as time allows.

> As opposed to one 33-change PR? Yes, absolutely yes they do.

100% this.

With remote teams spread across time zones, mega-PRs become even more problematic.

> one-liners

One commit for a single line? I can't imagine developing software this way. Fixing bugs? Sure. Altering this or that in a well-established, mature codebase? Probably. For features, I don't see how it's possible.

paperwork and red tape results in lower velocity. sometimes this is what you want.

note this is also true in software engineering.

The approach didn't drive quality. 1 team cared about their code and felt empowered to improve it, the other didn't.

The majority of people care about the quality of their work when they are starting off. Not caring is a learned behavior. When you repeatedly get reprimanded for it, you learn not to care as a way of protecting your mental health from taking even more damage.

I'm honestly baffled by this. You're a proponent of dealing with chores as you encounter them during development rather than putting them off til later (great! I love this!), but also when that PR lands you want it all squashed down into a single commit, which presumably will have a message like "Implemented Important Feature, also did a bunch of unrelated work".

That sort of workflow is ideal for making sure you've got a set of isolated commits each looking at a single subject so that when someone is reading through the history later they can quickly see where something was introduced or why, and jj is perfect for doing that because it makes crafting those commits so much easier.

What if you could have the best of both worlds?

Where the developers at that other company could “take out the trash” amidst one PR, jj makes it trivial to carve off each of those fixes into their own separate PR. It’s no more work than making them separate commits.

People don’t do this in git because it’s a hassle. So you either get cleanup that never comes because each branch needs to know in advance what work it’s going to do or you get omnibus PRs that do twenty different things.

There’s a better way, and it lets you have clean history and developers can fix things they run into along the way.

> That said, I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release.

This is the one thing I always point to when I say "Mercurial is better" (and now, jj).

Why can't we have our cake and eat it? Mercurial lets you have lots of individual commits, but they're hidden, and you'll see only the squashed commit. Why do we have to lose all those individual commits to get that squashed commit? The answer: You don't need to.

> I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release.

Hmm what's the issue with the GitHub default of merging PRs, where there's a merge commit which individually pulls in the PR's commits? You can revert the merge PR as a whole, or the PR commits individually. E.g. with this[1] merge commit, you can `git revert 0a98f570 -m 1` (the merge commit) or `git revert b30950fc` (an individual commit from the PR).

[1] https://github.com/amelioro/ameliorate/commit/0a98f570f63ffd...

> ...making small and tightly-focused branches that are easy to review and merge is very important.

> This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks.

This is exactly how I like to use git. Sounds like I should be recommending jj to colleagues who struggle with this approach.

The way I understand it, its for those who can't help but to fix B while working on A and want to make sure that they are two different PRs? The way I do it is after B is done, I just create a new branch and point B to A in the PR. A is pointing to dev/master/upstream. Does JJ make this workflow more convenient?

You'd probably like reading about the megamerge workflow. I and others have linked some articles in a few comments here already.

Yep! And it makes it convenient even when you need to make changes or add new commits onto A. B is constantly stitched up to remain a child of A and incorporate its fixes.

It also makes it simple and easy to split B and A apart such that both their parents are `main` if they’re unrelated.

You can also go hog-wild. I was working on a big refactor recently. I made independent changes A, B, C, and D (each one to three commits). I then wanted to work on code that assumed all of these commits were available, so I made a merge commit E that combined them. I then made changes F that depended on that refactor, so was a child of E.

Managing this was simple. If I needed to make updates or tweaks to A-D, E and F were updated to incorporate them automatically. `jj absorb` even meant that doing these types of changes was almost zero work: I could make a bunch of changes and the tool would know in which parent commit they belonged.

None of this was merged in yet. When I was ready, PRs went out for A-D. When they each merged into `main`, E became a no-op and was discarded. F became its own PR. This is something I never would have done in git because having multiple threads of unmerged code is a colossal hassle.

Can you go into some detail on how you do this? I use jj but it sounds like you make a change and then split it up into more changes after the fact, which I'm not familiar with yet.

I have a bad habit, even still, of just working in one monster commit.

It took me a few months to realize that I could use jj split to move specific files to a different commit. And then I'd sometimes squash them into related commits, rebase to move them around etc...

But I just discovered interactive split, which lets you move specific lines and sections from different files in a commit to a different commit. So I've been using that a lot more recently to organize the changes more thematically.

Ultimately I should try to become more diligent with adding a new commit any time I start doing something different - it's dead simple to do and even less friction to organize later - but I suppose that I'm not that inclined because the interactive split makes it so easy to do it all later that I just stay in the flow of my monster commits.

Everything is possible with jj.

just started making much more use of jj split to move split

Interactive split?! Very interesting, I'll look into that, thanks!

EDIT: I love it.

Haha, fantastic.

Also, if you didn't discover yet, you can use the arrow keys to unfold the different files and sections. Then select what you need, split the rest to new commit.

As you know, even when just using the most basic functionality (new changes, merges, rebases) of jj, it's amazing. But then you just keep discovering other features and workflows - none of which require any incantations - that make it that much better. And I'm sure I'm still only scratching the surface of its possibilities.

And, as I keep saying everywhere, jjui just takes the whole experience to another level.

If you end up with a commit that's a number of small fix-ups to files edited in earlier commits, `jj absorb` will push changes up to whichever (mutable) commit last modified the file they're in.

Thanks. I've been trying it recently but it never seems to do anything, so I just do squashes. Any idea why this might be?

One really nice trick you can do is:

- Create multiple topic branches, one for each thing you're working on.

- Now you probably want to work on item A while having B and C all available, so make a single merge commit (jj new a b c) to build on top of.

- Create further commits on top of that, while you're working.

- When you're cleaning up (ideally often), use squash --to or rebase --after to move those commits back the branch they belong on. This does not invalidate the merge commit; you will, effectively, have multiple branches checked out at once.

EDIT: This is apparently called the 'megamerge workflow'.

Megamerges are awesome, but what really makes them magical is when you start using `jj absorb`, which automatically splits and squashes your commit down to the nearest unambiguous commits and leaves anything that doesn't have an obvious place to live

I've been trying absorb recently and have found it rarely does anything and I just resort to squashes. Any idea what might be going on?

Absorb:

- Will not rewrite an immutable commit, of course. (Though you can tell it to, and for my personal repositories I sometimes actually set immutable() = root().)

- Will not do anything to diffs if it's uncertain where they should go, either because that file wasn't edited in a previous mutable commit, or because it was edited in multiple sibling/cousin commits. The latter is likely to happen with mega-merges.

You can use --into to restrict the set of target commits, if you already know what feature branch you're updating.

Yeah, I was already aware of megamerge. I use it.

But I'm still not disciplined enough to use it and other proper workflows consistently, especially when new features/topics spring up while working on another one. I just start working on it at the same time, and jj makes it simple to split it into its own commit and branch later.

I follow this methodology but I just ... use git? The hard part of making multiple small PRs is usually wrangling someone to actually review them, or following whatever process management has decided is necessary.

The hard part I always found without jj (and Fig before it, when I was at Google) was managing a DAG of small changes.

What's your git workflow for a change that depends on two other in flight changes? (More generally, of course, this can occur in an arbitrary part of one's change graph - which is usually not too deep, but at least in my experience, occasionally is.)

Having good tooling for this unlocked workflows I didn't know I was missing, and switching back to git when leaving Google felt like losing a limb.

> It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently.

Git has worktrees for that. If a parallel change is done in a separate worktree, it can be built and tested independently, which, I guess, is important for kernel developers, who are the initial target audience for git.

I think `git add -p` and its friends are another thing I'd point to for this.

I've never really struggled too hard to get git commits into different branches for review, but if you've put unrelated changes into the same working dir, you'll want `git add -p` to sort them out into multiple commits.

Note there are corresponding `-p` flags for things like git-restore and git-reset as well.

jj tends to use -i for 'interactive' to do what you do with -p in most git commands.

It is in fact a great tool, jj makes doing this even easier.

I'm sure it's great but I don't have the problems with git that others apparently do, so as to make it worth switching to a whole new mental mode of source code management.

At least uv solved real problems I was having with Python package management, but for my own personal usage git is 99% aligned with what I need.

I didn’t have problems with git either.

jj just makes all of the stuff I liked to do with git easier and faster, and lets me do some things you can’t do with git.

But you should use the tools you want to use.

Just FYI: The person you're responding to wrote a very popular tutorial on jj. He's been using git since the early days, and as he puts it:

> Now I am not one of those "the git CLI is too complex and git is too hard to learn" people, but I do acknowledge that puts me in the minority. But let's reframe that: if we can make something more powerful and easier? Sign me up!

> Just FYI: The person you're responding to wrote a very popular tutorial on jj.

That's nice.

I know of him better from his Rust work, but he explained himself well enough in his own comment that he probably doesn't need your assistance to reiterate a point he made very effectively on his own.

Also, he's not the only one who's used git since the early days.

I have no clue why you’re downvoted, I had upvoted you by the way.

Thanks. I was pretty snarky, in fairness, though I felt it was only matching the energy of that type of white knighting (which a decade ago I feel pretty sure would have gotten you downvoted into oblivion even on HN, but maybe I'm not hip with the times anymore! lol)

Let’s say you’ve checked out a new branch and done a bunch of work over the course of the last two hours.

You’ve added a new feature. In doing that, you’ve also fixed four unrelated bugs, clarified the documentation for a method you needed to use, and rewritten another function to be more performant.

You could push this all as six commits on one branch. PR reviewers will now have to figure out what parts are related to what, or read each commit one-by-one. If someone wants changes to one of these commits, your entire branch is held up.

Or you could split these six different commits out to each be directly on `main` and make a PR for each of them. They can be tested in CI, reviewed, and merged in isolation.

The latter is far better. You can do it in git, but it’s not exactly fun. It is trivial in jj.

This is the kind of example that I find insightful. I know I can do it with git and it's not hard. It's not fun, but it's not hard. So I will disagree with anyone who says that it's impossible with git.

But it is great to know that it is trivial in jj. That's a reason to try :-).

It’s definitely not impossible! It might not even be hard these days (git has accrued a million flags and features), but it is definitely friction. And it might not seem like much, but it adds up. And all of that friction stops you from even considering things that might genuinely be hard.

Everything feeling like it’s a slightly uphill battle isn’t something you always notice until it’s suddenly gone.

> You could push this all as six commits on one branch.

No, I'd probably put them all as individual branches to be reviewed, assuming they're truly independent changes. As long as they don't actually conflict it's not very hard to do this in git.

But this is kind of what I mean when I say that git fits my needs, because I wouldn't come across 4 unrelated tasks like this in the course of implementing a single commit's worth of features, unless I was having the world's biggest attack of ADD.

And if these things did need to get done to properly implement the feature to our team's quality standards, it would be appropriate to be included in that feature's PR as well.

I'm sure it's a nice tool, especially for those who work in domains where it takes a long time to land your commits into the main branch of development, but a lot of this sounds like solutions to problems that we don't all have.

jj also has worktrees, though they're called workspaces.

They're useful, but they're not really what your parent is talking about, your parent is talking about a workflow where you realize you've want to break up your work after the fact, rather than setting out to do it that way from the start.

To be clear, I haven’t used jj so please correct any misundersrandings. I hear you and agree that smaller PRs are definitely easier to understand. On the flip side, it sounds like jj just trades large PRs for lots and lots of smaller, independent PRs that are seemingly unrelated despite all belonging to the same change? I wouldn’t see that as better because, on face, it would sound like far more opportunity for changes to leak out of an actual change-set. Or is the suggestion that the advantage is that each one of those discrete changes carries a comment? Because if developers are lazy, which clearly it is laziness to not use stash for unrelated changes, why wouldn’t I expect every comment to eventually be “{feature}” for everything? So now we need to put more policies in place about how devs should spend more time commenting every one-line code change they make that became an individual PR? And I’m sure jj is going to provide me with a handy feature for then re-grouping all these changes together…back into the original big PR that would have existed in the first place? That seems like a circuitous route to arrive at the same place, but with added risk of unintentional, or worse, missing integration of parts of features that appeared to be independent changes? Ive never found it difficult when I make an unrelated change to just stash that change and add it to its own branch related to a bug ticket at the end of my day. Jj wouldn’t replace 90% of those processes so it sounds like a new way to avoid typing a few commands, by typing more commands more frequently and shifting the workload from a single large relevant change to many, many small changes, all of which were still part of the same set of changes.

None of that sounds like a positive to me, so I’d rather appreciate some evangelism to enlighten me and correct my misjudgments/misunderstandings which I fully admit are likely. :-)

I don't know why you think jj makes you produce many little commits. Are you thinking about the automatic snapshotting of the working copy? That amends (replaces) your previous commit, so you won't end up with a long chain of commits.

It's probably easiest to understand by just trying it. It can be used with regular Git repos.

>I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day.

Agreed. Having used SCCS, CVS, Subversion, VSS, Perforce, Clearcase, Accurev (the weirdest of the lot), Mercurial and Git, I'll move when the market decides what has critical mass and my job needs it.

jj feels a bit like learning a Dvorak keyboard and then being in an office of qwerty. Jobs want git, my colleagues know git, I'll be asked a question about... git. Using git has been the lowest version control churn in my brain for a decade, which is nice.

I mean, Git was a massive improvement over those other systems though. It was absolutely worth learning, and worth pushing companies to adopt. (Same with Mercurial, obviously.)

I still know git. I work at entirely git shops. Nobody has ever come to me with a problem I’ve caused, but people have come to me to ask how to switch.

I am also the guy who gets asked with doing crazy git things when the need comes up. I have another post here where a tricky and slow filter-branch that our company needed to do on a repo was a simple and obvious three-liner in jj.

> Jobs want git, my colleagues know git

And outside of a few scenarios, they can use git, you can use jj, and everyone will be happy.

I push to my team's Git repo using jj all the time.

I use like five commands total in Git and the rest is driven through my IDE which handles everything else. People who tell me Git is hard or recommend alternate tools are living in a different world.

It's totally possible to have no issues with Git, e.g. if you are only using it for small or slow moving repos.

There definitely are lots of big issues with Git though. I dunno how many jj solves but it doesn't seem unreasonable to suggest people move to a better system.

And I totally agree! And if jj works better for you, please use it!

My point is just that I am yet to find a convincing example that would suggest that jj would improve my workflow. If people find it hard to stash a change, I don't tell them that they shouldn't get their shit together and not use jj. But I don't find it hard to stash a change, so why do I feel like jj evangelists try to convince me that something is wrong with me?

This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use.

That just results in less friction, and in you doing things with it that you couldn't be bothered to before. Yes, I can switch branches in git by stashing my changes, and then I can try to figure out the five-levels-deep stash stack, but with jj I just switch between branches without finishing working on them, because it just works and is easy.

Yes, with git you can technically have five branches open at the same time, and stash work to switch between them to work on one thing or the other, but it's so hard and finicky that you end up never doing it in reality. Or, you can say "I never need that", but is it that you never need it, or that your tools make it so hard that you just subconsciously never do it? For me, it was the latter, as now I'm switching between branches ALL THE TIME, just because it's easy.

I've started, in this thread, likening it to Plato's Cave - people who are just using git are just seeing/using a blurry facsimile/projection of actual reality/possibilities. It's not a perfect analogy (jj is, I suppose, the projection, and people are chained in the cave), but it makes the point that there could be so much more.

The matrix or people happily in a cult would be similar analogies. Perhaps even Stockholm syndrome...

This is exactly why it feels like evangelism: "people who don't love jj haven't seen the light/are uninformed/live in the dark age/must be in a cult".

That kind of rhetoric makes me want to say "don't tell me I'm stupid if you are the one finding it hard to switch between git branches".

That's fine. Carry on

It is evangelism. Unabashedly. I think the Plato’s cave analogy is honestly apt.

Git was fine. I used git for ages. I loved its underlying model, and I think it’s brilliant. But it has a lot of sharp edges and a lot of tasks that are painful or frustrating, and people either opt to restrict themselves to a tiny subset to avoid the pain or they carefully curate a workflow that mostly does the job over the course of years.

Suddenly within a week of trying a new tool you just… don’t carry any of that any more.

It’s like going from GOTOs to structured programming with encapsulated functions. People made many useful programs with GOTO. Some people were more principled than others, but we all got by. But it turns out that functions and loops are a way better mental model for control flow than GOTO. Nobody had to switch and there were plenty of holdouts. But eventually the benefits were impossible to ignore.

People like Dijkstra evangelized structured programming because they “saw the light”.

You have a point, but it's more like it's difficult to articulate, than a cult.

I think of jj as the ultimate refinement of git. It's not revolutionary, in the sense that there's no must-have feature, but it's a distinct evolutionary upgrade that's just way more pleasant than git.

It's telling that most hard-core git gurus are lukewarm on jj at first, but for everyone else, jj makes it way easier to do guru-level version control.

Just my $.02, anyway.

This is one of the few comments here that make me feel like I should just try jj. Thank you, this is useful :-).

You're welcome! I've honestly really started doing stuff that git conditioned me into think I just didn't need, just because it made them hard to do.

> because there's no single thing that you can do with jj that you can't with git.

- jj undo, jj op restore, and jj --at-op to reset or view the repo at a previous state

- create multiple directories (workspaces) backed by a single repository at different commits

These are the only things I can think of off the top of my head that you can do with jj that you can't do with git.

> to reset or view the repo at a previous state

What about `git reflog`?

That lets you see previously checked out revisions. Jujutsu keeps track of all previous repo state. In git, you can pull a new remote branch, delete that branch, and push the deletion. If you want to get that branch back, git reflog will only save you if you checked out that commit. If you didn't, you're SOL. Jujutsu will let you undo the delete operation, restore the repo to a state where the branch existed, or view the repo at a state where the branch existed, and create a new branch at the same revision that the old branch was before it was deleted.

This is interesting, thanks!

That might be cool, actually.

FWIW, I cheated on a previous job for months by working 10% or so, then faking git commit data to spread it out across the week before sending a PR.

Thank you "git commit --amend --no-edit --date xxx"

What if you commit secrets to the repo by accident?

Just edit it out and don't push it to upstream?

Jujutsu repos only exists locally. There are no Jujutsu remotes, only git remotes. Repo properties unique to Jujutsu (repo history, stable revision IDs) are not pushed to git remotes.

> create multiple directories (workspaces) backed by a single repository at different commits

This is `git worktree`.

They don't work with submodules but submodules are a disaster that should be avoided anyway so probably no big loss there.

Ah, I was not familiar with that feature in git. In that case, I'll swap out jj workspaces for sparse checkouts :-)

Apparently git sparse-checkout exists! I'm going to stop guessing features that git doesn't have now.

> jj undo

Yeah - the other day I did a fetch, and then decided I didn't want to fetch. I simply ran "jj undo" to undo the fetch.

I like to phrase it as "jj enables everyone to be the git guru".

The git gurus responding how they can do X/Y/Z don't quite realize that git is still cumbersome enough that most people never bother to reach their level of proficiency.

Whereas jj is simpler, better-designed, and more powerful, so it's easier to start doing more advanced VC.

I also think everyone's underestimated how much universal undo enables exploration.

Ha! Good example!

Once I started using jj, I realized how poor/annoying git's stash is. You don't need a concept called stash in jj. You have some work done and want to stash it? Just leave it alone as a leaf node (or split your commit into a leaf node). Then branch off the parent to work on whatever you want.

And with jj, my "stashed" node is version controlled in itself. I can make changes to it, undo it, all while still being stashed. (Maybe you can do this in git - I don't know).

Other niceties of jj:

Why do I need to come up with a commit message only when committing? Why couple the two? With jj, you can just decide to work on X, write your commit message "Adding cat photos to Easter Egg", and then work on the feature. Or you can just start working, and in the middle of it all, add the commit message, and continue working. You can change the commit message at any point.

Why do I need to fix merge conflicts immediately? Just the other day in jj, I made a change, which resulted in a merge conflict in several nodes. Whatever - I just branched off a clean node and worked on what I needed to. Only the following day did I go and fix the merge conflict.

Why can I only merge two branches? And why do I need to think of from/to when merging? A merge is basically creating a new node that is the child of multiple nodes. It's symmetric - there's no from/to. And you should be able to specify 10 parents if you want to.

I feel like it's cat vs bat.

bat just is more useful even if you didn't have issues with cat

Actually I find this tutorial to make a really good point in introducing it Jujutsu [1] without implying that "if you don't know it you don't know the Truth/haven't seen the light/are a peasant".

The author starts by saying that they actually have no issue with the git CLI, which is exactly my case.

I started trying jujutsu and until now, I can describe the feeling as an ergonomic keyboard: I am fine with any keyboard, really, it's not that some keyboards are "hard to use". Nobody would (should?) say "with a cheap keyboard, you can't type fast enough to be efficient, but with this ergonomic keyboard, you will be faster". But one may find that an ergonomic keyboard is more comfortable for them, or that it sounds a bit better or feel a bit better.

There is no real need to change keyboard if you like yours. It doesn't mean that it's impossible to find another keyboard that would be more pleasant to use.

JJ may be that (for me, but again I'm just starting): it seems equivalent to git CLI (as in, it's not a heavy GUI or a VScode plugin: it's really a CLI) and it feels like it may be more ergonomic.

And at the very least, it's fun to try.

[1]: https://steveklabnik.github.io/jujutsu-tutorial/

> You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff

Wit the added bonus that "bim" won't remain popular enough to sustain its development for long, so "bim" users have to switch to the fork "bbim" in 2 years, that won't remain popular enough to sustain its development for long...

How do you know? Maybe jj would be a productivity improvement for you. Maybe it wouldn't. There's only one way to find out and it seems like a pretty painless thing to try. If this is your attitude toward new things do you still pump water out of a well when you're thirsty?

How much time do you spend resolving merge conflicts between multiple team members?

In good approximation, I would say around 0 minute a week. I guess it could happen that it takes a few minutes, but I don't remember last time it happened.

yea i am really confused by all these issues people are saying they have myself..stashing merging etc...and what is crazy is we migrated large teams of programmers who's only experience with version control before git was microsoft TFS and and everyone is easily and happily chugging along. Now most of these people use gui tooling for managing git, but so what everyone gets it done with no issues or complaints with many projects big and small. we even have non-devs using it. I get jj might have some life improvements for some niche groups of people but i really have to wonder if they are the type of people who purposely make their life more complex

Forget between team members - it's an issue just for my own local dev purposes, when I'm working on multiple changes/PRs at the same time and want to test them all out before they get merged to main in the origin.

This is also true of vim. You have to move to Helix. It's very similar to vim, but different enough that you have to learn new stuff.

Reply on news.ycombinator.com