jj – the CLI for Jujutsu

https://steveklabnik.github.io/jujutsu-tutorial/introduction/what-is-jj-and-why-should-i-care.html

by tigerlily • 3 months ago

549 493 3 months ago

steveklabnik.github.io

dgb23• 3 months ago

The last paragraph might be the most important one:

There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without requiring anyone else you're working with to convert too. This means that there's no real downside to giving it a shot; if it's not for you, you're not giving up all of the history you wrote with it, and can go right back to git with no issues.

eru• 3 months ago

Funnily enough, that's how I used git with CVS and Subversion, too.

jeremyjh2• 3 months ago

But this is not true. They are interoperable but far from seamless. Those features mainly support migration use cases or things like git deployment from an repo managed in jj. Operations git does are not in jj’s log. You have to constantly import them. The project recommends a single primary interface.

miyoji3• 3 months ago

But it is true. I (and many others) happily use jj on teams that use git without anyone else on the team using jj or knowing (or caring) what I'm using.

maleldil3• 3 months ago

If you constantly switch between the two, you're going to have a hard time, but you can take a git repo, try jj for a while, and if you decide to go back, you don't lose anything.

ongy• 3 months ago

I think you are talking about colocation, which is slightly different than the `jj git push` `jj git fetch` type commands.

Colocation has its uses bit is a bit finicky. The push/pull compatibility works perfectly fine (with some caveats of github being broken that can be worked around).

asdfasgasdgasdg• 3 months ago

Most importantly, submodules are not fully supported, which are used by almost every open source project at least in the space I work in (embedded). So you can't use jj to easily contribute back to those project. It can be done but you always have to be cognizant of whether a submodule has changed between two branches or when you sync, since they don't update automatically the way they do with git.

saghm21• 3 months ago

It's been over a year since I last used git manually in the CLI, and I've exclusively worked with git remotes. The only time I had any friction was on a team where stale code-gen output was checked into the repo and for whatever reason no one was willing to either add it to the `.gitignore` or commit (pun intended) to keeping it up to date, meaning that I had to manually remove the changes from when I compiled before pushing. I would have argued in favor of adding to .gitignore or keeping it up to date even if I didn't use `jj` though because I think having stale output checked in is just silly.

IshKebab2• 3 months ago

Big caveat: do not try to use Git and JJ in the same directory. It's probably fine if you only use JJ, but if you mix them you will horribly break things.

surajrmal7• 3 months ago

This isn't true?

chriswarbo5• 3 months ago

I suppose it depends what you mean by "horribly break things".

The only thing I've noticed is that `jj` will leave the git repo with either a detached HEAD, or with a funny `@` ref checked out.

I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

For someone who's less experienced, or only uses git for a set of branches with mostly linear history (like a sort of "fancy undo"), I could imagine getting a shock when trying to `git commit` and not seeing them on any of the branches!

verdverm3• 3 months ago

Unless you use LFS, submodules, or hooks at your org.

igor47• 3 months ago

Submodules work fine but yeah, it's frustrating that lfs is taking so long. But there seems to be some momentum recently https://github.com/jj-vcs/jj/pull/9068

tucnak2• 3 months ago

16 year-old me would have been very impressed by this!

auggierose• 3 months ago

Is that a compliment, or the opposite?

tucnak2• 3 months ago

A bit of both. I guess it's nice, but nothing I actually care about.

jansan2• 3 months ago

We all need to give ourselves a push and finally make the next step in version control. Github, Google, Microsoft, Meta (did I forget anyone relevant? Probably) should just join forces and finally make it happen, which should not be a problem with a new system that is backend compatible to Git. Sure, Github may lose some appeal to their brand name, but hey, this is actually for making the world a better place.

ramblerman• 3 months ago

The new solution is better. It’s so good we must get all the big players to mandate its usage.

If ur making an appeal on a forum like this u could have gone with ur favorite feature, or anything else really.

jansan2• 3 months ago

It is not about starting over, like moving from CVS or Subversion to Git. jj is backend compatible to Git, so nothing really had to change on the backend.

It's just that although Git was created by Linus Torvalds it is not perfect and could be more beginner friendly. But efforts to improve this should be concerted, not individual efforts.

And it does not have to be jj. I just think there is room for improvement, and not to alienate old farts it could be called GitNext, GitStep, GitFlow or similar to emphasize that is still is just Git, only with an improved front end.

Maybe Linus Torvalds himself should start the initiative.

SOLAR_FIELDS• 3 months ago

Every time I see a statement like this I wonder what specific features of git that people feel like are terrible enough that it’s time to completely start over. Besides “the UX is kinda shit and it’s confusing to learn”, which there are many solutions for already that don’t involve reinventing a pretty good wheel.

seanhunter2• 3 months ago

Right.

How we got git was cvs was totally terrible[1], so Linus refused to use it. Larry McEvoy persuaded Linus to use Bitkeeper for the Linux kernel development effort. After trying Bitkeeper for a while, Linus did the thing of writing v0 of git in a weekend in a response to what he saw as the shortcomings of Bitkeeper for his workflow.[2]

But the point is there had already been vcs that saw wide adoption, serious attempts to address shortcomings in those (perforce and bitkeeper in particular) and then git was created to address specific shortcomings in those systems.

It wasn't born out of just a general "I wish there was something easier than rebase" whine or a desire to create the next thing. I haven't seen anything that comes close to being compelling in that respect. jj comes into that bucket for me. It looks "fine". Like if I was forced to use it I wouldn't complain. It doesn't look materially better than git in any way whatsoever though, and articles like this which say "it has no index" make me respond with "Like ok whatever bro". It really makes no practical difference to me whether the VCS has an index.

[1] I speak as someone who maintained a CVS repo with nearly 700 active developers and >20mm lines of code. When someone made a mistake and you had to go in and edit the repo files in binary format it was genuinely terrifying.

[2] In a cave. From a box of scraps. You get the idea.

mhh__• 3 months ago

Git is basically fine even though the verbs are backwards - e.g. you shouldn't need to name branches, commits should be far more automatic, but the basic mechanisms are fine.

GitHub is an abomination.

bluGill• 3 months ago

Coming from mercurial (which is older than git), git doesn't understand a branch. Instead of a branch you get a tag that moves, which is very different. Too often I'm trying to figure out where something came in, and but there is just a series of commits with no information of which commits are related. Git then developed the squash+rebase workflow which softof gets around this, but it makes commit longer (bad), and loses the real history of what happened.

Git was not the first DVCS, there were better ones even when it was made. But Linus pushed git and people followed like sheep.

(I'm using git, both because everyone else is, and also because github exists - turns out nobody even wants a DVCS, they want a central version control system with the warts of SVN fixed).

l72• 3 months ago

If git would change two defaults, that would make me really happy:

  1. git merge ONLY does merges (no fast forward/rebase). git pull ONLY does a fast forward
  2. git log by default is git log --first-parent. Just show commits where the parent is the current branch. This makes the merge workflow really easy to understand an linear, because in the end, you only care about commits on the trunk.

tom_alexander10• 3 months ago

I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you create a new branch off of the old commit and add an empty commit to that branch so any file changes don't end up rewriting the past 2 weeks of history. git is much nicer in that I can do whatever I want to the files and it won't change the repo until _I tell it to_.

smackmybishop2• 3 months ago

Just don't ever use `edit`, use `new` instead; then your changes are tracked without making a mess. I think that's much nicer than juggling stashes in git.

VMG2• 3 months ago

... unless you actually want to edit a change!

embedding-shape2• 3 months ago

Just don't ever use `edit`, use `new` instead

As a git-ist (?), if I'd ever move away from git, it would be to avoid tooling that has idioms like this (like git too has), if `jj` just gonna surface a bunch of new "bad ideas" (together with what seems like really good ideas), kind of makes it feel like it isn't worth picking up unless you don't already know git.

busfahrer2• 3 months ago

Once you get your head around it a bit, doing a new in this circumstance will be second nature, since you will have realized that a `new XYZ` in jj leads to the same underlying git state as a `git checkout XYZ` in git

jdkoeck2• 3 months ago

Wow, that’s a total deal breaker to me. Using git may require a complex mental model, but at least it’s not doing anything I didn’t ask for.

Diggsey• 3 months ago

You would have had to run `jj edit` in order for this to happen, so I think it's a stretch to say you didn't ask for the edit?

This is the main difference though: in git files can be `staged`, `unstaged` or `committed`, so at any one time there are 3 entire snapshots of the repo "active".

In `jj` there is only one kind of snapshot (a change) and only one is "active" (the current working directory). When you make changes to the working directory you are modifying that "change".

As others have mentioned, the equivalent to `git checkout` would be `jj new`, which ensures a new empty change exists above the one you are checking out, so that any changes you make go into that new change rather than affecting the existing one.

saghm21• 3 months ago

Using `jj edit` will edit a commit you specify, and `jj new` will make a new empty commit after the one you specify. These work exactly the same whether you specify a commit by branch or by the hash. I'd argue that you're getting exactly what you ask for with these commands, and by comparison, what "checkout" is asking for is much less obvious (and depends on context). We've just internalized the bad behavior of git for so long that it's become normalized.

stouset4• 3 months ago

`jj edit` is quite literally asking for that.

GP is holding it wrong. If you don’t want to edit a commit, don’t ask to edit it. Use `jj new`.

csmantle• 3 months ago

`jj new` works like `git checkout` most by creating an empty revision on the top. `jj edit` on the other hand resembles `git checkout; [edits...]; git add -A; git commit --amend --no-edit`.

arianvanp• 3 months ago

You can disable the auto staging of new files since recently which removed the main grype for me

tom_alexander10• 3 months ago

ooo that will be a nice improvement. So many times I've run `jj status`, then saw a file I wanted gitignored, so I'll edit my gitignore, but the file has already been added to the repo so I have to `mv <file> /tmp/ && jj status && mv /tmp/<file> .` to get the file out of the repo.

smweber2• 3 months ago

jj edit is the biggest jj footgun I can think of, as other comments said just use jj new. But also if you do accidentally edit or change something jj undo works surprisingly well.

I found when using jj it worked best for me when I stopped thinking in commits (which jj treats as very cheap “snapshots” of your code) and instead focus on the “changes”. Felt weird for me at first, but I realized when I was rebasing with git that’s how I viewed the logical changes I made anyway, jj just makes it explicit.

jj auto-rebasing doesn’t matter until you push changes, and once you do it marks them immutable, preventing you from accidentally rebasing changes that have been shared.

saghm21• 3 months ago

jj edit is the biggest jj footgun I can think of

Honestly, this is only because `git checkout` is so convoluted that we've collectively changed our expectations around the UX. "checkout" can mean switching to another branch (and creating it if you specify a flag but erroring if you don't), looking at a commit (in which case you have "detached HEAD" and can't actually make changes until you make a branch) or resetting a file to the current state of HEAD (and mercy on your soul if you happen to name a branch the same as one of your files). Instead of having potentially wildly different behavior based on the "type" of the thing you pass to it, `jj edit` only accepts one type: the commit you want to edit. A branch (or "bookmark", as jj seems to call it now) is another way of specifying the commit you want to edit, but it's still saying "edit the commit" and not "edit the bookmark". Unfortunately, the expectation for a lot of people seems to be that "edit" should have the same convoluted behavior as git, and I'm not sure how to bridge that gap without giving up part of what makes jj nice in the first place.

nomel2• 3 months ago

preventing you from accidentally rebasing changes that have been shared.

I think this ruins it for me then. I push my in-progress work, to my in-progress branches (then git-squash or whatever later, if needed). It makes switching between (lab) computers, dead or not, trivial.

Is there some "live remote" feature that could work for me, that just constantly force pushes to enabled branches?

Jenk5• 3 months ago

This is literally jj's schtick and reason for existing, so I wouldn't be surprised if you decide it is not the tool for you.

tom_alexander10• 3 months ago

Yeah, that's a very real possibility. On the bright side, jj is git-compatible so at least the two camps can live together in harmony.

saghm21• 3 months ago

How are you "checking out" the old commit? It sounds like you're using `jj edit`, which I'd argue does what it says on the tin. Switch to using `jj new <branch>` and your problem goes away.

tom_alexander10• 3 months ago

That avoids the problem for the specific workflow of checking out an old revision (and it was what I was describing with checking out a new branch off the old commit and adding a blank commit to that branch), but another way this design bites me: At work I am constantly jumping around numerous repos because I might be working on repo <foo> but then someone on my team will ask for help with repo <bar>. So I'll turn on screen sharing, open up repo <bar> and I'll type out psuedo-code into <bar> as I'm explaining things to them.

So if the last thing I did on <bar> was finish some work by making a new commit, then writing some changes, and then giving it a commit message with `jj desc`, then I am now polluting that commit with the unrelated explanatory psuedo-code. So when switching to a repo I'm not actively working in, I need to defensively remember to check the current `jj status` before typing in any files to make sure I am on an empty commit. With git, I can jump around repos and make explanatory edits willy-nilly, confident that my changes are distinct from real meaningful commits.

I guess one way to describe it is: we want to make it easy to make good commits and hard to make bad commits. jj seems to be prioritizing the former to the detriment of the latter. My personality prioritizes rigorous safety / lack of surprises.

et1337• 3 months ago

Jujutsu has a concept of mutable vs immutable commits to solve this. Usually everything in a remote branch is immutable. To work on a branch, I track it and that makes it mutable.

alunchbox2• 3 months ago

if you loose an edit jj op log is incredible, I've saved a ton of work more-so now with AI's making mistakes. Also workspaces are super fast compared to git worktree's - same concept, different implementation.

I agree, that was a bit of an interesting approach but more-so than not it's been better in DX even though you have to 'unlearn' long term it's been a benefit IMO, but a soft one, not something you can measure easily.

baq16• 3 months ago

edits to files are automatically committed

this is a core feature and it makes jj possible - you're supposed to get used to jj new and jj squash into the previous bookmarked commit, which you map to the git branch head/PR.

IOW you're supposed to work on a detached git head and jj makes this easy and pleasant.

rstuart41339• 3 months ago

so you need to defensively create empty new commits for your changes.

I thought that for a long while too, and was equally pissed. Then I happened upon `jj evolog`. Turns out jj had a better solution than staging all along - I just didn't realise it existed.

The move from using jj as an alternate porcelain to git to using it efficiently took me more months than I care to admit. I suspect being familiar with git cli is actually a handicap in learning jj. New users without pre-conceptions will have a much easier time of it.

And oddly, I also suspect they will also end up knowing more about the underlying git storage engine than git users. It turns out it's capable of being used far more effectively than git uses it.

Doubly oddly, I blame Linus's familiarity with CVS and SVN for that. He (correctly) bemoaned how unsuited to the job of distributed source code management they were and invented a storage engine that has proved to be remarkably good at the job. But he carried across many the concepts in their CLIs to gits porcelain. Jj (with a lot of help from hg), finally broke free of that legacy.

simonmic2• 3 months ago

You can turn that off (I do). In your config file:

    [snapshot]
    auto-track = "none()"

Auto-tracking could be a great default in certain projects, and a terrible one in others. jj doesn't require it at all and is still awesome without it.

Bonus tips:

    # show help by default, as the subcommands do
    [ui]
    default-command = "-h"

    # more readable log (also affects jjui)
    [templates]
    log = 'builtin_log_oneline'

7e• 3 months ago

Is it better for AIs? That’s the only reason I would care.

VMG2• 3 months ago

I've had mixed results.

Most models don't have a 100% correct CLI usage and either hallucinate or use some deprecated patterns.

However `jj undo` and the jj architecture generally make it difficult for agents to screw something up in a way that cannot be recovered.

glasner• 3 months ago

I've gone all in on jj with a OSS framework I'm building. With just a little extra context, the agents have been amazingly adapt at slicing and dicing with jj. Gives them a place to play without stomping on normal git processes.

nvader• 3 months ago

Try using https://github.com/danverbraganza/jujutsu-skill

This is enough of a command reference that with it, agents are able to work with jj pretty well.

joshka4• 3 months ago

The cli and a few concepts have evolved with time past the model's knowledge cutoff dates, so you have to steer things a bit with skills and telling it to use --help a bit more regularly.

I find it reasonably good with lots of tweaking over time. (With any agent - ask it to do a retrospective on the tool use and find ways to avoid pain points when you hit problems and add that to your skill/local agents.md).

I expect git has a lot more historical information about how to fix random problems with source control errors. JJ is better at the actual tasks, but the models don't have as much in their training data.

rob74• 3 months ago

Still not finished unfortunately :( Guess Steve is currently busy writing the next big thing in programming languages (https://steveklabnik.com/writing/thirteen-years-of-rust-and-...) ?

surajrmal7• 3 months ago

It hasn't been touched in 3 months: https://github.com/rue-language/rue .

BeetleB14• 3 months ago

To be honest, while Steve's tutorial was what got me interested in jj, other tutorials were better in actually helping me understand it.

steveklabnik49• 3 months ago

This is why I'm glad we have many of them! Not everyone is going to resonate with my writing style.

steveklabnik49• 3 months ago

Nope, I have had zero time for personal projects lately, Rue is on the backburner until I do.

I've been busy at https://ersc.io/ (and spending time with my family, and playing Marathon...)

shuyang3• 3 months ago

Has anyone found a good code review workflow with `jj`? My problem is that GitHub doesn't remember the content of the last reviewed SHA, so every time I push a new change from jj, reviewers lose the delta from their last reviewed commit.

To work around this I stopped moving revs (squash/rebase) after review starts, which creates awkward local graphs if I have to merge from main for merge conflicts. Graphite works but it's $$$, and phabricator/reviewable/gerritt all have significant onboarding hurdles.

roblabla• 3 months ago

I wonder if the recent github stack system could help with that (https://github.github.com/gh-stack/guides/ui/)

shuyang3• 3 months ago

waitlist only :/ waiting to get in so i can test it out!

bananapub• 3 months ago

github added support for this in the last six hours - https://github.github.com/gh-stack/faq/#will-this-work-with-...

joshka4• 3 months ago

The last reviewed sha is generally available on the PR page (not the changes page) when you force push. There should be a changes since review link somewhere near the push.

When reviewing, you can also mark individual files as reviewed (useful in larger reviews where you're incrementally reviewing files). If you do this, only files that are changed will be expanded when you come back to the review.

shuyang3• 3 months ago

yeah, this is where my complaint is - github shows a "compare" button when I force push, but it's not linked to the PR review. The "file changed" status is often not granular enough - if I change one line, force push, the entire file gets marked as unreviewed. the github "changes since your last review" is commit-based, not sha-based.

what I want is something like graphite/gerritt/google's critique where after each force push, the review page shows only the true delta between the two shas (similar to the "compare" button in github, bu as a reviewable unit).

poked around on github, doesn't look like the stacked PR feature has affected this "changes since your last review" selector yet :(

nerdypepper• 3 months ago

https://tangled.org does exactly what you want :)

have a longer write up here: https://blog.tangled.org/stacking but we have "interdiffs", to view a delta from previous review. pull-requests advance in the form of immutable rounds much like the patch workflow on email.

we have been interdiffing and stacking for a while on to dogfood, sample PR: https://tangled.org/tangled.org/core/pulls/1265/round/1?diff...

saghm21• 3 months ago

I haven't noticed any significant change in my workflow needed to accommodate this, but it might be because I've always used rebase rather than merge. `jj rebase -d main` will put my current branch on top of the main branch, and fixing conflicts in `jj` is a breath of fresh air compared to git.

swoorup2• 3 months ago

I love jj, but mostly I use jjui.

I would like more uniformity in the way jjui handles commands when you are viewing changes vs when you are viewing files within a single change.

Often I just make my changes and leave it there without `new`, as I am not sure which file should go in a single commit. I just leave it there and I interactively commit later.

For me to use `new` more, I would like the ability to also simply be able to get a tree view of all changes, which contains file which contains file changes, so I could can have marks that span multiple changes and then either `split` or `commit` or `squash` the change, idk if there is a good word for it. Right now I can only mark within a single change, and I lose it once I navigate up.

joshka4• 3 months ago

I use jj fairly regularly and I'm trying to understand what your approach means, but having difficulty following what you want to acheive here. Seems like you're using ambiguous language that isn't aligned - wdym by marks?

gcr3• 3 months ago

In jjui, you can select multiple changes to squash/rebase by pressing space bar before pressing S or r. Is that what you mean?

swoorup2• 3 months ago

yes exactly, pressing space bars to select them. I referred these selection as marks.

nchmy3• 3 months ago

yeah, i know almost nothing about jj because i only use it via jjui. Why would I waste brain power learning about and remembering new incantations when I can just browse around with arrow keys and mouse and then use like 9 hotkeys to do everything that I could possibly need?

PUSH_AX• 3 months ago

If it ain't broke...

surajrmal7• 3 months ago

I think there are a lot of things that work well but still get improved versions. For example, grep works well but there are plenty of better versions these days.

newsoftheday5• 3 months ago

Really? I use grep multiple times per day, works great, I've seen no need to change. Same with git.

BeetleB14• 3 months ago

As a Mercurial user, git was broken from day 1 :-)

butlike• 3 months ago

FWIW, it's a pretty decent fried fish chain in Chicago as well.

cestith2• 3 months ago

And chicken. And they have a few other things like Italian beef.

They’re branching out, too. We had one in our neighborhood in Houston before moving back here to Illinois.

dhruv3006• 3 months ago

this looks pretty interesting.

enbugger• 3 months ago

1) Are there any benefits in replacing a personal private project git repo with jj? I usually just commit straight to master in order to just not to lose the changes and be able to roll back. 2) Are there any pros in doing so in a project with many large binary files (3d models, images)?

Jenk5• 3 months ago

You don't replace. jj is backed by git anyway.

gcr3• 3 months ago

You can switch an existing git repo to jj by using:

jj git init --git-repo my-repo

I think (but CANNOT PROMISE) that just removing the .jj folder will bring you back, but definitely take a backup of .git before you try this in case I’m wrong.

ncphillips6• 3 months ago

Okay but why would they use jj when they do trunk-based dev

andrepd• 3 months ago

Is there a concise introduction / overview of jj? I've read 8 pages of this link and the author is still in preambles and considerations... Not my favourite style of article!

marcuskaz• 3 months ago

I wrote a brief intro to Jujutsu here: https://mkaz.blog/code/jujutsu-vcs

simonmic2• 3 months ago

This is great, thanks.

SAI_Peregrinus2• 3 months ago

You have a DAG of "changes" to the repo state. Each change has a stable ID, you can modify its contents or description without changing the ID. There's always a "current" change checked out, JJ automatically snapshots your edits to files into this change. JJ provides tools to edit changes, describe them, group them into named branches (bookmarks), reorder them, split them apart, etc.

JJ defaults to being backed by git. Each change has a corresponding git commit. When you edit the contents of a change, jj makes a new git commit & points the change at that new git commit. JJ is never actually amending or editing git commits, it's using git as a content-addressed data store.

That's the mental model. It's like git with a lot of accidental complexity (staging area, stashes, commit ID instability) removed.

There are a few ways you can work with this model. I like the following:

When I want to start new work, I fetch any changes from upstream `jj git fetch`, then make a new change after the current `main` or `master` bookmark: `jj new main`. Then I start writing code. When I want to commit it, I type `jj commit` and write a description. If I find I want to make an edit to a previous change, I edit my working copy and interactively squash to that change ID with `jj squash -i -r <change_id>`. When I'm ready to push those changes, I name the branch HEAD with `jj bookmark create`, then push it with `jj git push -b <bookmark_name>`. If there are review comments I squash edits into the appropriate changes or add new changes, and move the bookmark to the new head with `jj bookmark move`. If I want to merge two (or more) branches, I use `jj new <branch_1_name> <branch_2_name> <...>` to make a new commit with those branch names as parents. If I want to rebase some changes I use `jj rebase`. JJ doesn't care about conflicts, I fix them after a rebase has completed, instead of in the middle.

jampekka• 3 months ago

That sounds a bit faffy. In solo or small team work git is often git pull, edit code, git commit -a, git push.

With jj you have to fetch, start new space off a bookmark, edit code, commit it, update the bookmark and finally push?

steveklabnik49• 3 months ago

I can be a bit verbose, it's true :)

You've got some decent replies, but if you give me some background, like how comfortable you are with git, how much you care about certain details, I'd be happy to respond here with something more concise.

tiborsaas• 3 months ago

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow.

I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state.

Since it's git compatible, it feels like it must work to add files and keep files uncommitted, but just by reading this tutorial I'm unsure.

Jenk5• 3 months ago

It doesn't need you to think that way at all.

`jj new` simply means "create a new commit [ontop of <location>]" - you don't have to describe it immediately. I never do.

I know that the intention was to do that, and I tried forcing the habit, but I too found it counter-productive to invariably end up re-writing the description.

surajrmal7• 3 months ago

I don't usually do that right away, but I often use squash or absorb to move additional changes into a commit I already made in my stack. I think the spirit still applies if you take that course.

smweber2• 3 months ago

My preferred workflow is to start with a new change, pick the changes I want, then use jj commit to describe the change and create a new empty one on top. Feels very similar to my old git workflow.

If I end up with multiple features or abstractions in one change (equivalent to the “dirty repo”), jj split works very well as an alternative to the git add/git commit/repeat workflow tidying up one’s working copy.

pythonaut_16• 3 months ago

I also like `jj commit [paths]` to commit just a subset of files when I don't need hunk based splitting.

Like `jj commit -m 'Feature A' file1 file2` then `jj commit -m 'Feature B' file3 file 4`

joshka4• 3 months ago

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow.

A good way to think of it is that jj new is an empty git staging area. There's still a `jj commit` command that allows you to desc then jj new.

I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state.

jj split allows you do to this pretty well.

Since it's git compatible, it feels like it must work to add files and keep files uncommitted, but just by reading this tutorial I'm unsure.

In jj you always have a commit - it's just sometimes empty, sometimes full, has a stable changeid regardless. jj treats the commit as a calculated value based on the contents of your folder etc, rather than the unit of change.

saghm21• 3 months ago

I often will use `jj new -B@` (which I made an alias for) followed by `jj squash -i` to split changes. I had no idea about `jj split`, so I need look into that!

greenicon• 3 months ago

I'm using jj exactly this way, but `jj commit -i` is still somewhat backwards compared to `git commit -i`: jj displays the commit timestamp by default instead of the author timestamp like git. In addition, in jj the author timestamp of a commit is set to the time you started and not ended a commit/change. This results in unexpected timestamps when working with git-using people or tools. Also, it's rather weird if you use a previously empty commit for your work which was created months earlier by a previous `jj commit`, resulting in a timestamp neither correlating to when you started nor ended your work.

I guess the idea of jj's authors is that jj's commits are far more squishy and can always be changed, so a fixed finished timestamp makes less sense. I still prefer git's behaviour, marking work as finished and then keep the author (but not commit) timestamps on amends.

I use this jj alias to get git's timestamp behaviour:

  [aliases]
  c = ["util", "exec", "--", "bash", "-c", """
  set -euo pipefail
  change_id=$(jj log -r @ --no-graph -T 'change_id')
  desc=$(jj log -r $change_id --no-graph -T 'description')
  commit_author=$(jj log -r $change_id --no-graph -T 'author.email()')
  configured_author=$(jj config get user.email)
  
  jj commit -i "$@"
  
  if [ -z "$desc" ] && [ z"$commit_author" = z"$configured_author" ]; then
      echo "Adjusting author date"
      jj metaedit --update-author-timestamp --quiet $change_id
  fi
  """]
  
  [templates]
  # display author timestamp instead of commit timestamp in log
  'commit_timestamp(commit)' = 'commit.author().timestamp()'

frio• 3 months ago

A good way to think of it is that jj new is an empty git staging area. There's still a `jj commit` command that allows you to desc then jj new.

This always made me feel uncomfy using `jj`. Something that I didn't realise for a while is that `jj` automatically cleans up/garbage collects empty commits. I don't write as much code as I used to, but I still have to interact with, debug and test our product a _lot_ in order to support other engineers, so my workflow was effectively:

    git checkout master
    git fetch
    git rebase # can be just git pull but I've always preferred doing this independently
    _work_/investigate
    git checkout HEAD ./the-project # cleanup the things I changed while investigating

```

Running `jj new master@origin` felt odd because I was creating a commit, but... when I realised that those commits don't last, things felt better. When I then realised that if I made a change or two while investigating, that these were basically stashed for free, it actually improved my workflow. I don't often have to go back to them, but knowing that they're there has been nice!

miyoji3• 3 months ago

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow.

Yes, but this is not backwards, the way you do it in git is backwards. =)

SiempreViernes2• 3 months ago

git promises "version control", this clearly implies that the versions predate the control: in this picture the git workflow is not backwards.

saghm21• 3 months ago

Nothing stops you from making changes in a commit that has no description and then at the end doing `jj commit -m` to describe them and make a new commit in one go, which is essentially the same as git. The difference is that it's essentially amending in place as you make changes rather than needing to stage first.

fmckdkxkc• 3 months ago

Personally haven’t used jj but as far as dvcs’s are concerned Fossil is great complement to Git because it does things differently than git and truly has a decentralized feel.

The autosync feature is really nice too, and you can store backup repos in cloud storage folders and auto sync to those as well.

59nadir• 3 months ago

Fossil is delightful and definitely nails a feeling of decentralization that I think we ruined completely with `git` by constantly centering around centralized repositories.

I also find it interesting that so many people want to switch to something that's not `git` but are simultaneously somehow super invested in it being basically just `git`.

Most teams could switch to Fossil and just have a better time overall. It's made for smaller, high-trust teams, `git` is not. Fossil also manages to actually support external contributions just fine; it's just that it's not the default.

jezzamon• 3 months ago

That totally works and it's how I use jj. jj commit -i does what you would want

EliasWatson2• 3 months ago

jj is very flexible when it comes to workflow. One thing to note is that commits don't have to have messages. What I tend to do is to run `jj new` frequently while I work on something and leave all of them without messages. Then when I'm ready to make my actual commit, I squash the temporary commits together and then add a message. If my changes are separable, I can split the commits before squashing. This workflow acts as a kind of undo history. I can easily go back to what I had 5 minutes ago and try a different approach, but then also jump back to my original changes if I want. It makes experimentation much easier compared to git.

minraws2• 3 months ago

think of jj like,

I want to build xyz,

```

jj desc -m "feat: x y & z"

```

do the work.

```

jj split

```

Split up the parts and files that you want to be separate and name them.

This will also allow you to rename stuff.

```

jj bookmark create worklabel-1 -r rev1

jj bookmark create worklabel-2 -r rev2

# Push both commits

# since we just split them they are likely not inter-dependent

# so you can rebase them both to base

# assuming rev1 is already on top of base

jj rebase -s rev2 -d base

jj git push

```

That is it.

motbus32• 3 months ago

I am dumb. why is that better than a git branch or a git worktree ?

baq16• 3 months ago

it's actually git that makes you think backwards - in jj the working tree is a commit, in git it isn't until you at least stage it.

the working tree being a commit has wide ranging implications as all the commands that work with commits start working with the working tree by default.

shermantanktop• 3 months ago

This is me! I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion.

Hence I have multiple workspaces, and I shelve changes a lot (IntelliJ. I end up with dirty repos too and that can be painful to cherry-pick from. Sometimes I just create a git patch so I can squirrel the diffs into a tmp file while I cleanup the commit candidate. I often let changes sit for several days while I work on something else so that I can come back and decide if it’s actually right.

It’s chaotic and I hide all this from coworkers in a bid to seem just a bit more professional.

I admire people who are very deliberate and plan ahead. But I need to get the code under my fingers before I have conviction about it.

chriswarbo5• 3 months ago

I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion.

I do that all the time. With git, everything starts "unstaged", so I'd use magit to selectively stage some parts and turn those into a sequence of commits, one on top of another.

With jj I'd do it "backwards": everything starts off committed (with no commit message), so I'd open the diff (`D` in majutsu), selecting some parts and "split" (`S` in majutsu) to put those into a new commit underneath the remaining changes. Once the different changes are split into separate commits, I'd give each a relevant commit message.

sfink3• 3 months ago

I'm about the same. jj is kind of perfect for that. Example:

# I've finished something significant! Carve it out from the working "change" as its own commit.

    `jj commit --interactive` # aka `jj commit -i` or `jj split`, depending on how you prefer to think of it: making a commit for some work, or splitting a separate commit out of the working change.

# Oops, missed a piece.

    `jj squash --interactive` # aka `jj squash -i`

# Let me look at what's left.

    `jj diff`

# Oh right, I had started working on something else. I could just leave it in the working change, but let me separate it out into its own commit even though it's unfinished, since I can always add pieces to it later.

    `jj commit -i`

# Wait, no, I kind of want it to come before that thing I finished up. Shoot, I messed up.

    `jj undo`

# Let me try that again, this time putting it underneath.

    `jj split -B @-` # aka `jj split --insert-before @-`. @ is the working change, @- is its immediate parent(s), @-- is all grandparents, etc.

# Note that instead of undoing and re-selecting the parts, you could also `jj rebase -r @- -B @--` to reorder. And in practice, you'll often be doing `jj log` to see what things are and using their change ids instead of things like `@--`.

# I also have some logging code I don't need anymore. Let me discard it.

    `jj diffedit`

# Do some more work. I have some additions to that part I thought was done.

    `jj squash -i`

# And some additions to that other part.

    `jj squash -i --into @--`

# etc.

There's a lot more that you could do, but once you internalize the ideas that (1) everything is a commit, and (2) commits (and changes) can have multiple parents thus form a DAG, then almost everything else you want to do becomes an obvious application of a small handful of core commands.

Note: to figure out how to use the built-in diff viewer, you'll need to hover over the menu with the mouse, but you really just need f for fold/unfold and j/k for movement, then space for toggle.

chriswarbo5• 3 months ago

It wants me to start with the new and describe command

jj doesn't "want" anything.

I always end a piece of work with `new`: it puts an empty, description-less commit as the checked-out HEAD, and is my way of saying "I'm finished with those changes (for now); any subsequent changes to this directory should go in this (currently empty) commit"

The last thing I do to a commit, once all of its contents have settled into something reasonable, is describe it.

In fact, I mostly use `commit` (pressing `C` in majutsu), which combines those two things: it gives the current commit a description, and creates a new empty commit on top.

gcr3• 3 months ago

Think of it this way: the current change is like a staging area/index in git. Leave it without a a description while you're working (just like git's staging area). Rely on jj's auto-snapshotting to capture all your changes. Then, when you're ready to do something else, give it a description ("jj describe") and switch to a new blank change ("jj new"), and that becomes your new "staging area"/index.

The workflows are conceptually identical.

benoitg• 3 months ago

Not necessarily, I often make changes on unrelated commits. You can always use jj split to extract the change and put it somewhere else.

nchmy3• 3 months ago

JJ doesnt prefer you to do anything. I regularly just create description-free commits, do whatever, then name them later (or squash, split, absorb the changes into other commits). It is exceptionally flexible and forgiving. Even moreso if you use jjui, the best TUI ive ever used.

stouset4• 3 months ago

Does JJ really prefer for me to think backwards?

No, you run `jj new` when you’re done with your work just like you’d run `git commit`. You can even just run `jj commit` which is a shorthand for `jj describe && jj new`.

arialdomartini• 3 months ago

Yes, that’s idiomatic in JJ. Honestly, I’ve been recommending the same workflow (first commit, then make changes) with Git too since years

https://arialdomartini.github.io/pre-emptive-commit-comments

If you want to have a workflow similar to Git with index, check out the Squash Workflow: basically, you would edit your files in a disposable commit having the same purpose of Git’s index.

tiltowait• 3 months ago

I tend to approach jj commits as local PRs. Decide what it is I'm working on, make a new, empty commit on top of that :

    jj new -m 'do thing'
    jj new

As I work on the "local PR", I `jj squash` my working changes into the named commit. By keeping my working commit description-free, I avoid accidentally pushing it (and potentially broken code) to origin.

aryehof• 3 months ago

Does JJ really prefer for me to think backwards?

Perhaps it’s the other way around. I have a standard agentic instruction to summarize prompt instructions using jj describe. After it makes changes I can see both the file changes made and a log description of what prompted those changes. When done it’s just jj new and its ready for the next set of prompts.

palata2• 3 months ago

I tried jj for a few months. It was fun to learn a new thing, but I haven't had a single case of "wow, this would have been a pain with git". Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed".

So it felt like the XKCD on "standards": I now have one versioning system, if I learn jj I will have two. What for?

Don't get me wrong: it's nice that jj exists and some people seem to love it. But I don't see a need for myself. Just like people seem to love Meson, but the consequence for me is that instead of dealing with CMake and Autotools, I now have to deal with CMake, Autotools and Meson.

EDIT: no need to downvote me: I tried jj and it is nice. I am just saying that from my point of view, it is not worth switching for me. I am not saying that you should not switch, though you probably should not try to force me to switch, that's all.

naasking3• 3 months ago

Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed".

The core issues are: how long did it take you to get there, how many lucky decisions did you have to make to not run into git footguns, and how many other people accidentally made different choices and so have very different experiences from you?

palata2• 3 months ago

What you're saying is that other people may find jj easier for them, right?

I am fine with that. I am just saying that the "you should use jj, you will finally stop shooting yourself in the foot regularly" doesn't work so well for me, because I don't remember shooting myself in the foot with git.

BeetleB14• 3 months ago

For me, it was kind of the same. I used jj. Really liked it, but did not find it all that much better than git.

Then, for various reasons, I switched back to git.

By day 2, I was missing jj.

Stuff like "jj undo" really is nice.

demorro• 3 months ago

This doesn't seem different enough to be worth the transitional cost, even if you don't need to actually move away from a git backend.

maleldil3• 3 months ago

It is definitely worth a try. Just being able to squash changes to earlier commits without having to fiddle with fixups and interactive rebases is worth it for me. jj absorb is great too.

scotty792• 3 months ago

Does jj have partial clones of remote repo?

steveklabnik49• 3 months ago

jj does not have partial clones, but it does have sparse checkouts.

scotty792• 3 months ago

Thank you for the info.

Sparse checkouts from remote repo directly or do I need to clone it in whole locally and only then can do a sparse checkouts into some work directory?

systems• 3 months ago

its almost impossible for me to tell if this better or worst than git i read few things about jj, and my conclusion

   1. its different
   2. very few user would really care about this difference

i think git is good (not good enough, good just good, or really good) and unlike shells, i cant think of a reason to have mass migration to it

people use zsh because apple choose it, and pwsh because microsoft settled on it, on linux i am sure we can do better than bash, but it good enough and nothing justified replacing it (that being said, all 3 OSes should have settled non nushell)

in summary, if we couldnt replace bash on linux, i dont think anyone can replace git, git as an scm tool if far better than bash as a shell

porksoda2• 3 months ago

I may be reading too deeply but it sounds like you haven't even tried it. You should! Its really hard to live without it, once you feel it in your fingers.

kccqzy• 3 months ago

very few user would really care about this difference

Oh the user absolutely does if that user creates lots of branches and the branches are stacked on top of each other.

I get your feeling though; sometimes in my own private repositories I don’t bother creating branches at all. Then in this case jj doesn’t really make much of a difference.

em-bee7• 3 months ago

we may have not been able to replace bash yet, but the popularity of alternative shells that are not bash compatible is growing. besides nushell there are fish, elvish, murex, oils (also includes a bash compatible mode to help with the transition) and probably some others that i missed. i see more and more tooling support for some of these, which shows that usage of these shells is growing.

qezz• 3 months ago

For those, who want to/need to keep some files uncommitted, the workaround I found is to put gitignore into some nested directory:

  mkdir junk
  echo '*' > junk/.gitignore

jj won't track those files under ./junk/

Also might be relevant for claude, since it wants to put its settings into the repo itself as `.claude/`:

  mkdir junk/.claude
  bwrap ... --bind "$(pwd)/junk/.claude" "$(pwd)/.claude" ...

For some more common files, I use global gitignore file as

  # ~/.gitconfig
  [core]
    excludesFile = ~/gitconf/gitignore_global

  # ~/gitconf/gitignore_global
  .envrc
  .direnv/*

tcoff913• 3 months ago

I run jj in colocated mode so I put stuff in .git/info/exclude if I want it ignored but not part of the main .gitignore

BeetleB14• 3 months ago

You can also set snapshot.auto-track to tell it not to track certain files.

Another option is to make a branch with the files that you want to keep around but not push (e.g. stuff specific to your own tooling/editor/IDE), and mark that branch as private. Private commits (and their descendants) can't be pushed.

You then make a merge commit with this branch and main, make your changes, etc. You will have to rebase before pushing so that your branch isn't a descendant of the private commit.

This will involve more work, but it has the benefit that you're actually version controlling your other files.

nailer3• 3 months ago

JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects.

What has a change is ast-based version control.

You adding a feature to a function that uses a struct I renamed shouldn't be a conflict. Those actions don't confliuct with each other, unless you treat code as text - rather than a representation of the logic.

Ending merge conflicts might make a new version control 10x better than git, and therefore actually replace it.

saghm21• 3 months ago

JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects.

The difference is that I can (and do) use `jj` with existing git repos today without needing anyone else using the repo to change what they're doing. There's no need to replace something when it can exist alongside it indefinitely.

cageface• 3 months ago

Unless you need to work with a repo that uses submodules or lfs.

celdon25• 3 months ago

Did you confirm that the network effects are applicable here before posting that?

nailer3• 3 months ago

Nope. As mentioned "What is jj and why should I care?" didn't cover it and I timeboxed jj advocacy to the page that says it will get me to care.

aftbit2• 3 months ago

Nope, git is good enough, and is the global standard. We don't need more new VCS.

cryptos• 3 months ago

Might be true, but Subversion was also good enough and a de-facto standard.

aftbit2• 3 months ago

IMO Subversion was never as much of a standard as git. I saw a lot of software that still used CVS back then, and even more that didn't do version control beyond versioned source tarballs.

I'd be happy to be proven wrong. You won't get there by designing a solution that is more ergonomic (if jj even is), but rather by designing one that solves problems that git doesn't solve. Also, you probably need to get some big and important software (like Linux, for git) to switch to using it instead of git.

Even then, I'm usually _not_ an early adopter of something as pivotal as a VCS. This isn't something that's easy to rip out or rewrite later. It shapes my workflow at a deep level and holds the history of my changes in its database. Only once it's being used by 25-50% of projects I encounter daily will I consider moving stuff I control to it.

I have deep scars from mercurial lol.

porksoda2• 3 months ago

Great opinion. Have you tried it? It takes just 30 minutes to wash all the Stockholm syndrome off of you.

homebrewer• 3 months ago

Not necessarily. I used jj for a couple of weeks and found it to be a complete waste of time.

For an advanced user, it did not offer anything I cannot quickly solve in git. Which is probably the wrong thing to optimize in the first place, because even though I frequently rewrite history and split commits during normal worklfow, it takes so little time that improving something else would yield greater returns.

We (not royal we) don't usually go out of our way repeating negative experiences with these tools, so you build a very skewed view of their adoption.

newsoftheday5• 3 months ago

Their opinion is great, why do you feel like you need to counter it with [but, but jj is for the clean masses, not the unclean users].

justinmayer• 3 months ago

Many folks aren’t aware that there is also an open-source, cross-platform desktop GUI application for Jujutsu called GG: https://github.com/gulbanana/gg

I mention it because while the jj command line interface is excellent, there are certain tasks that I find easier to perform with a graphical user interface. For example, I often want to quickly tap on various revisions and see their diffs. GG makes that kind of repository browsing — and certain squash operations — much more efficient for me.

If you’re interested in more information about GG, my co-host and I talked about it in a recent episode of the Abstractions podcast at about the 8:17 mark: https://shows.arrowloop.com/@abstractions/episodes/052-they-...

tcoff913• 3 months ago

jjui TUI is incredible also

ferfumarma• 3 months ago

Can jj iterate through a list of repositories and clone them all to local storage?

It isn't very hard to make a bash script to do it, but I have about six github repos, all of which frequently need to be put on a new machine. that kind of functionality would be cool to have out of the box.

hosteur• 3 months ago

    for url in url1 url2 ..; do git clone $url; done

That’s not really a script but a basic one liner.

Filligree• 3 months ago

No, but to be honest, why would you want it to? That's... well, you already showed the trivial one-liner.

saghm21• 3 months ago

Are you accessing these boxes via ssh or using them directly? If it's via ssh, I'd expect that you would already be using the clipboard for copying the names of them rather than typing them out manually, at which point copying `git clone <a> && git clone <b> && ...` would achieve the same thing.

zingar• 3 months ago

"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.

baq16• 3 months ago

does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count?

if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.

alphabetag675• 3 months ago

Actually it is a anti-demo, because while software allows you to do it, I don't think many software engineers can work on this.

VanTodi• 3 months ago

Guess he was talking about the presentation, not what the tool can achieve. It has no hard proof on the first page, which could easily just be a LinkedIn pitch, but not on hackernews

tinco• 3 months ago

It might count, but it is easy with git as well, what is the feature in jj that makes this easier? Switching branches and pushing changes to remotes is the core feature of git and in my opinion really easy so I'm curious how jj improves on it.

VonGallifrey• 3 months ago

Can you show how you would do this in jj?

I know how I would do this in git, but don't really see how this would be in jj. I currently don't use it in my workflow, but if it is super easy in jj then I could see myself switching.

steveklabnik49• 3 months ago

This is good feedback, for sure, thank you. It's sometimes hard to come up with truly concise examples, but that's also why they're so valuable.

ersatz-matty4• 3 months ago

Consider using the table of contents on the left of the page to view "Real World Workflows", "Branching, Merging, and Conflicts", and then "Sharing Your Code with Others" and then evaluate how JJ does things against your current git workflow. This requires some minor effort on your part.

The official JJ docs also have a "bird's eye view" introduction and tutorial available here: https://docs.jj-vcs.dev/latest/tutorial/.

EDIT: Jujutsu for Git experts: <https://docs.jj-vcs.dev/latest/git-experts/>. This outlines some of the main advantages relatively succinctly.

latortuga• 3 months ago

Yeah we moved on from SVN to git because SVN branches were truly a pain in the ass to work with. I truly do not have any rough edges or big pains in my day to day git workflow.

qznc• 3 months ago

There is no index anymore. I guess that is the "easier" part.

steveklabnik49• 3 months ago

That is, but not directly.

The general idea here is that jj has fewer and more orthogonal concepts than git. This makes it more regular, which is what I mean by "easy."

So for example, there is no index as a separate concept. But if you like to stage changes, you can accomplish this through a workflow, rather than a separate feature. This makes various things less complex: the equivalent of git reset doesn't need --hard, --soft, --mixed, because the index isn't a separate concept: it's just a commit. This also makes it more powerful: you can use any command that works on commits on your index.

This is repeated across jj's design in general.

surajrmal7• 3 months ago

Specific commands don't really showcase the appeal of jj. If anything they might scare someone at first glance. It's the fact that the workflows are intuitive and you never find yourself reaching for help to get something done. You really need to try it to understand it.

tomnipotent• 3 months ago

that the workflows are intuitive

It can't be both intuitive and yet too complicated to show examples at the same time.

WesolyKubeczek• 3 months ago

The only intuitive interface is the nipple. All other things are learned.

I feel very comfortable using git. Maybe jj is better, but not seeing is not believing.

EliasWatson2• 3 months ago

A couple things off the top of my head:

- You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later.

- Manipulating commits is super easy (especially with jjui). I reorder commits all the time and move them between branches. Of course you can also squash and split commits, but that's already easy in git. Back when I was using git, I would rarely touch previous commits other than the occasional squash or rename. But now I frequently manipulate the commit history of my branch to make it more readable and organized.

- jj acts as a VCS for your VCS. It has an operation log that is a history of the state of the git repository. So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone.

- Unnamed branches is the feature that has changed my workflow the most. It's hard to explain, so I probably won't do it justice. Basically you stop thinking about things in terms of branches and instead just see it as a graph of commits. While I'm experimenting/exploring how to implement or refactor something, I can create "sub-branches" and switch between them. Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I want to test something but I have current changes, I just `jj new`. And if I want to go back, I just make a new commit off of the previous one. And all these commits stick around, so I can go back to something I tried before. Hopefully this made some sense.

Also note that jj is fully compatible with git. I use it at work and all my coworkers use git. So it feels more like a git client than a git replacement.

coldtea2• 3 months ago

All of these features sound like the recipe for a confusing nightmare!

"You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later."

"Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I want to test something but I have current changes, I just `jj new`. And if I want to go back, I just make a new commit off of the previous one. And all these commits stick around, so I can go back to something I tried before."

capitainenemo• 3 months ago

I also like the powerful revision querying mechanisms that they pulled in from mercurial. They seem to work just like mercurial revset queries which can be used in various operations on sets of revisions.

I would like them to have mercurial's awesome hg fa --deleted when it comes to history trawling, but apparently for it to work well, they also need to swap out git's diff format for mercurial's smarter one, so I'll be waiting on that for a while I suppose.

rasguanabana• 3 months ago

So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone.

It’s possible to recover from these with git reflog, though.

Rebelgecko• 3 months ago

"jj undo" is worth the price of admission by itself.

See the current top thread on HN about backblaze not backing up .git repos. People are flaming OP like they're an idiot for putting a git repo in a bad state. With jj, it's REALLY HARD to break your repo in a way that can't be fixed by just running "jj undo" a couple times.

rstuart41339• 3 months ago

What makes jj better requires a mindset change. When you start with jj, you use it as an alternate porcelain for git, meaning you just use the jj commands that map to the way you used git. You have to let go of that mindset. Until you do, you are still using those old git commands; they are just have prettier clothing. The prettier clothing is not worth the effort.

I don't know how to explain a mindset to you, so I'll give one example of something that sounds so grand, it seems impossible. (There are so many unusual aspects to jj, but hopefully this is one you can immediately relate to.) Git famously makes it hard to lose work, but nonetheless there are commands like `git reset --hard` that make you break out in a sweat. There is no jj command that destroys information another jj command can't bring back. And before you ask - yes of course jj has the equivalent of `git reset --hard`.

zhaoyongjie• 3 months ago

To be honest, JJ is dick in Chinese, literally.

verdverm3• 3 months ago

https://chinese.stackexchange.com/questions/31646/is-jj-slan...

mi_lk• 3 months ago

Please update the "Stacked PRs" workflow article Steve...

steveklabnik49• 3 months ago

I'll get there... someday...

ux266478• 3 months ago

Clicked on this hoping it would be the irc client, very disappointed!

For those in the know, how does jujutsu stack up to something like Darcs?

steveklabnik49• 3 months ago

jj is still snapshot based.

BeetleB14• 3 months ago

One of my favorite jj features is "jj absorb".

For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit.

Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to.

Oh, and not having to deal with merge conflicts now is awesome. My repository still has merge conflicts from months ago. I'll probably go and delete those branches as I have no intention to resolve them.

xixixao• 3 months ago

git absorb exists too fyi

bitdivision• 3 months ago

Not by default: https://github.com/tummychow/git-absorb

dnmc• 3 months ago

And If `jj absorb` gets it wrong, you can run `jj undo`.

This is such a killer feature to me. I'm not scared to start potentially gnarly rebases anymore because I can painlessly undo.

BeetleB14• 3 months ago

Yes. With "jj undo", I'm not scared to do anything. The brief time I had to go back to using vanilla "git", I didn't enjoy being extra cautious.

Using a version control tool shouldn't require much self discipline.

nchmy3• 3 months ago

yeah, i regularly try absorb then undo when it moves it to a commit from 7 years ago, then manually squash where appropriate

jhhh• 3 months ago

After hearing about a workflow that used absorb I wrote a simple git version I called 'squash-index' in about 15 lines of bash in a few minutes. Since git allows subcommand extension I just made an executable 'git-squash-index' and everything worked as if it was a builtin subcommand. I get that initial ergonomics are important for new tools but if the only novel feature is reified merge conflicts it doesn't really seem worth making the switch. No one needed to evangelize git to people like myself who had worked with a variety of old version control systems (cvs, svn, etc). It was just obviously much, much better. jj seems like it streamlines certain things, and might be worth learning for new users who have no git experience, but doesn't really differentiate itself enough for people who've been using git for a long time.

BeetleB14• 3 months ago

How easy is it to version control the index and stash in git? Do I need to know any other commands?

With jj, it's the same as any other commit. No new commands, no new options.

SV_BubbleTime4• 3 months ago

You can request to not use the pager by using jj st --no-pager, or if you hate the pager and want to turn it off, you can configure that with

    $ jj config set --user ui.paginate never

In one feature they can’t help themselves from calling it two different things already.

Why do this? Why can’t the very clearly smart people making things step 1/2 step outside themselves and think about it like they are the users they want?

Earlier they talk about the native format and how it isn’t ready… so that to start you need

    jj git init

… but… if they’re planning a native format that makes no sense as a command. It would be ‘jj native init’ later?

Early planning keys/plans imo but those rarely change so as to not accept your early adopters.

These seem like small things but to me it’s a warning.

Philpax3• 3 months ago

1. Pagination with a pager is a reasonable default. See `git log`.

2. The native format would be `jj init`. For precedent, see how uv dealt with its pip compatibility: `uv pip install` was obsoleted by `uv add`.

SV_BubbleTime4• 3 months ago

1. No one with good vision would give a single feature two names. It’s dumb. Here is our pager feature. Cool, how do I access it? Oh you set the ui.paginate options of course!!

2. It’s almost like we have some established ways to denote arguments that are pretty popular… ‘jj init —-git’ for example? By using ‘jj git init’ I would expect all of the git compatible commands to be be ‘jj git xxx’ because that is a reasonable expectation.

This is a problem with the voodoo. These obscure nonsense commands only makes sense when you are accustomed to them. If there’s no reasonable expectation that you could just figure it out on your own. Go on vacation and come back and be surprised when you forget the voodoo. Not to mention that every tool has to have its own unique voodoo.

Almost like the professional world has figured out that made by software engineers for software engineers will never be popular. And then engineers don’t understand the effects of why you might want tool to be intuitive and popular.

QuiDortDine4• 3 months ago

$ cargo install jj-cli@0.23.0 --locked

I won't install Rust just to test your software. Make a debian package like everyone else.

harg• 3 months ago

I believe the full docs page does indicate that there are binaries to install via popular package managers [1]

[1] https://docs.jj-vcs.dev/latest/install-and-setup/

QuiDortDine4• 3 months ago

I did check that page, as far as I can tell you still need to run Cargo which I don't want to do because I don't care about Rust.

I'm not complaining for the sake of complaining, I'm saying if they want to play in the Big Boy leagues, they need to do things right.

Philpax3• 3 months ago

Immediately after that line:

If you're not a Rust developer, please read the documentation to figure out how to install things on your platform

Rather selective reading we have here, don't we?

QuiDortDine4• 3 months ago

I did! No apt install jujutsu. I also did 'apt search jujutsu'.

Don't ask me to care about yet another language's package manager, I already know way more than I wish to.

rstuart41339• 3 months ago

They do publish binaries they work perfectly well on Linux. No need for cargo:

https://github.com/jj-vcs/jj/releases/tag/v0.40.0

randyrand• 3 months ago

jj sounds awesome. I think I’ll give it a shot.

But I found this article a bit long winded and ended up asking an LLM about it instead.

jrockway• 3 months ago

jj is great and while it was an adjustment at first, I've never looked back. I feel like when you're working with other people, things never get reviewed and merged as quickly as you'd like. With jj, it's pretty low-cost to have a bunch of PRs open at once, and you can do something like `jj new <pr1> <pr2> <pr3>` to build stuff that requires all 3. This lets me do things like... not do a big refactoring in the same PR as adding a feature. I can have them both self-contained, but still start on the next step before they're all merged. It's easy to add changes on top, switching between the individual PRs as comments come up, etc.

I always liked doing things like this. At Google where we used a custom fork of Perforce, I told myself "NEVER DO STACKED CLs HAVE YOU NOT LEARNED YOUR LESSON YET?" If one CL depended on another... don't do it. With git... I told myself the same thing, as I sat in endless interactive rebases and merge conflict commits ("git rebase abort" might have been my most-used command). With jj, it's not a problem. There are merge conflicts. You can resolve them with the peace of mind as a separate commit to track your resolution. `jj new -d 'resolve merge conflict` -A @` to add a new commit after the conflicted one. Hack on your resolution until you're happy. jj squash --into @-. Merge conflict resolved.

It is truly a beautiful model. Really a big mental health saver. It just makes it so easy to work with other people.

andrewdea4• 3 months ago

I'm having trouble understanding the value of this and most other supposed advantages of jj I'm seeing. I'm trying to pinpoint if it's because 1) my workflow doesn't need jj's fancy stuff, 2) I've gotten so used to `git`'s "flaws" that I don't notice them, or 3) the git porcelain I use (magit) does a good enough job at managing the flaws.

If you need to build on something that requires changes from 3 open PRs, can't you just start a new branch from main, merge all 3 PRs into it, and get to work? As changes are applied to the open PRs, you can rebase. Obviously that might cause some merge conflicts here and there, but as long as the PRs aren't super overlapping, they should still be manageable. If there's a ton of overlap between 3 open PRs, that to me sounds like a problem in the workflow/plan, which must be dealt with regardless of the VCS or porcelain.

steveklabnik49• 3 months ago

For me, it wasn't so much that jj enabled things I couldn't do before, though there are some things. What it enabled was me doing the things I was doing, but in a more easy way. This also leads you to do things that you can do, but sometimes avoid because it's a lot of work.

wolttam2• 3 months ago

What happens when jj introduces this native repository format - break compatibility with all the popular git hosts?

If jj is so great now and works with git as a backend, it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend.

steveklabnik49• 3 months ago

Nothing will break. You just keep using the git backend if you want to keep being compatible with git.

it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend.

Well, there's no active work on a "native" backend. There are basically three backends right now:

1. the git backend

2. A simple backend used for tests, you can think of it almost like a mock backend, you wouldn't use it for real work, but it's still useful as part of the test suite

3. the piper backend at google

There's not a lot of reason for anyone to produce another open source "native" backend, because 99% of open source projects use git.

wolttam2• 3 months ago

That makes sense, thanks for the reply. For some reason I was under the impression that there was an active drive towards a backend that was not git.

kevin_nisbet• 3 months ago

I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git.

What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it again at some point, but working in a team through Github PRs that was my main barrier to entry.

steveklabnik49• 3 months ago

This is good feedback, thanks. The next version of the tutorial will certainly focus on stuff like this, as I agree it's really important to teach people.

p_stuart82• 3 months ago

locally? sure. stacked changes in jj are great. but the moment you push to GitHub, the review UI still thinks in SHAs. a lot of the pain just moves from the author to the reviewer.

opem2• 3 months ago

I see that is an issue with many people, but now with github adding support for stacked PRs, I guess that would change

theappsecguy2• 3 months ago

I'm still struggling most with the fact that my day-to-day work involves a git first platform like GitHub.

Although jj as a vcs system, it does feel better, working with git through it still feels like a chore, but to be fair I only gave it a day before going back to git.

Does anyone have any good resources on how to augment a git flow through the lens of a git hosting platform to work smoothly and still reap the benefits of jj?

r5Khe• 3 months ago

I'm not sure what the hangup is, TBH. I use `jj` with GitHub and ADO every day, and it works great.

What specific challenges are you running into that make it feel like a chore?

theappsecguy2• 3 months ago

Hmm, it was a while back so now I'm struggling to recall, but I remember feeling like I'm going against the grain of easily using GitHub. I followed this exact tutorial at the time and it looks like there are now sections on how to work with GitHub.

Perhaps I need to force myself to commit for longer...

BeetleB14• 3 months ago

What problems are you running into?

The jujutsu docs have a page for this - it has everything I needed.

https://docs.jj-vcs.dev/latest/github/

fallat3• 3 months ago

Now that Steve is part of a GitHub competitor to push jj, I see all these posts as just sales pitches.

Philpax3• 3 months ago

This tutorial predates his involvement with ERSC.

steveklabnik49• 3 months ago

I am quite happy for anyone to use whatever tools they find to be good. I'm also happy for anyone to use jj with whatever server they want to.

It is right to be skeptical of me, but I hope to keep that integrity by continuing to talk about things that I believe are legitimately good, regardless of anything else.

fallat3• 3 months ago

Thanks for the reply Steve - I think it's only natural, and charitably unintentional :) But almost everything I've seen upvoted around the Internet from you has been about jj and being directly tied to east river source control... I think that's a reasonable framing. I can only hope me signalling this maybe changes something. While I'm not a fan of jj (I'd much rather Pijul were to eat the world), I think you as a person is really nice and always have been "for the community", but I can't shake this current framing!

octocop• 3 months ago

Nobody is asking for a git replacement? I keep seeing these posts and I don't know who wants them.

SatvikBeri• 3 months ago

jj has almost 30,000 stars on github. You might not be looking for a different git ux, but plenty of people are!

vaylian• 3 months ago

You could have said the same thing about subversion.

Subversion is a fine VCS. But git offers a better approach with being offline-first and decentralized. It also makes merging branches a lot easier.

I don't know enough about jj to praise it, but I don't think git will be the last VCS that will become widely popular.

steveklabnik49• 3 months ago

I wasn't asking. I loved git.

But then after trying jj, I wrote this tutorial because I love it even more.

__turbobrew__• 3 months ago

The feeling I get with jj is it is almost like people are trying to convince others why jj is superior instead of just sharing that jj exists and let others decide themselves. It seems like every few months there is a jj post on HN which devolves into the narratives of “git works for me” and “but jj is better at X”.

ncphillips6• 3 months ago

Where X = something I’ve never wanted to do

chriswarbo5• 3 months ago

Exactly the same thing happened when git showed up (alongside the same things for bzr, darcs, hg, etc. too!)

klauserc2• 3 months ago

I definitely am. Haven't touched git in over a year. If there was just a single feature to point at where jj meaningfully improves on git, I think it's: `jj undo`.

It is a universal undo command. It works for every change in your repository. You don't need to memorize/google/ask claude how to revert each individual kind of operation (commit, rebase, delete branch, etc.). You try a jj command, look at your repo, and if you don't like what you see, you `jj undo`.

The biggest downside for me is that no longer have the necessary expertise to help coworkers who get themselves into trouble with git.

newsoftheday5• 3 months ago

Agreed and not only that but for any comment on this page which raises a valid exception; there is a cadre of jj devotees ready to counter them if and where they think they can. It feels like someone had a some financial state in brainwashing the world to leave git for jj.

baq16• 3 months ago

I'm asking for a github replacement, alas it might come from github itself with stacked PRs.

git is good, but jj is good, too. nobody asked for a better CVS either, until someone did.

andrewdea4• 3 months ago

are you conflating github and git? I'm just confused as to how jj is a replacement to github

crazygringo• 3 months ago

Yes they are. I am. Many other people are too.

git was a great step forwards, but its conceptual model just doesn't map well to a lot of workflows, and some very simple things are very difficult or impossible with it. It was designed using a certain set of assumptions and primitives, and other assumptions and primitives turn out to be much more suitable for certain workflows.

I don't know if jj is the perfect answer, but it's a huge step forwards in many ways.

alunchbox2• 3 months ago

So glad to see this on HN, here to support it. JJ is amazing, the hardest hurdle was not the tool but the toolchain and ecosystem when I started ~ 2 years ago. It's grown rapidly and is incredible to see the community grow!

steveklabnik49• 3 months ago

Hey folks!

So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it.

Happy to answer any questions!

klauserc2• 3 months ago

jj automatically hides "uninteresting" changes. Most of the time, this is good.

Occasionally, I need to see more changes. It is not obvious to me how I get jj to show me elided changes. I mean, sure, I can explicitly ask jj to show me the one ancestor of the last visible change, and then show me the ancestor of that one, etc. Is some flag to say: "just show me 15 more changes that you would otherwise elide"?

steveklabnik49• 3 months ago

I use `jj log -r ..` for that, which is just an open ended range. It's not the "15 more" but it's what's worked for me. I suspect you could do it with some sort of revset stuff, but I like to keep it simple.

nickisnoble2• 3 months ago

Easy: `jj log -n 25`

(Default is 10 iirc, so if you want 15 more... 25)

If you want everything, ever: `jj log -r ::`

Or every ancestor of your current change: `jj log -r ..@`

rstuart41339• 3 months ago

I'm not sure what you are asking, but you want to look at how a particular jj change-id evolved over time, use `jj evolog`. By default that evolution is hidden. The `change-id/N` syntax has uses beyond conflicts.

opem2• 3 months ago

I think one major difference between git and jj is how immutable their DAG is, due to the difference in how they refer to their unit of change (i.e. stable change ID with changing commit IDs vs. immutable commit ID). One implication of that is change history in a git repo feels much more immutable to the one in a jj repo. Consequently operations that involves changing the history like, undo/rebase feels much easier/flexible. Is my understanding correct?

steveklabnik49• 3 months ago

Sorta! I think it can feel that way at times, but also the opposite. jj’s changes are immutable in the same way commits are, when you modify a change, it makes a new immutable commit and associates that with the change. So on the literal level, they’re the same.

But it’s true that mutating history is easy and sometimes even automatic with jj, whereas it’s not with git. So that could make it feel more mutable. On the other hand, jj has the concept of mutable vs immutable commits; jj will present you from modifying certain changes unless you pass in a flag to override it. So in some ways, it’s more immutable than git.

Just really depends on your perspective.

rs5458373• 3 months ago

jj is genuinely great and I think it deserves way more adoption than it has right now. The mental model is so much cleaner than git, undo actually works the way you'd expect it to, and working with stacked changes feels natural instead of that constant low-grade anxiety of actually breaking something. It's probably the best frontend for version control that exists today.

For the last few months though I've been thinking a lot about what you said at the end there. What if version control actually understood the code it was tracking, not as lines of text but as the actual structures we write and think in, functions, classes, methods, the real building blocks? A rename happening on one branch and an unrelated function addition on another aren't a real conflict in any meaningful sense, they only look like one because every tool we have today treats source code as flat text files.

For enhancing this kind of structural intelligence I started working on https://github.com/ataraxy-labs/sem, which uses tree-sitter to parse code into semantic entities and operates at that level instead of lines. When you start thinking of code not as text there's another dimension where things can go, even a lot of logic at the comiler level with call graphs becomes useful.

jiggunjer• 3 months ago

I think the mental model is like C vs python. Git gives you a forensic trace back in time. jj gives you a story with chapters. Look under the hood you'll still see forensic map of state transitions, but this not what we want to navigate most of the time. Sometimes we need to rewrite an early chapter to make the latest chapter make more sense.

baq16• 3 months ago

the fact that almost by definition stuff that jj does is possible in git makes it hard for some folks to let go of the baggage that git has; it's simply hard to imagine a world where you can't git add ('how do you commit what you need committed and not commit the rest?') or not having to resolve conflicts immediately ('why would I want not to?')

...and it turns out when you answer these questions differently ('working tree is a commit', 'conflicts can committed) but still want git compatibility, jj kinda falls out of the design space by necessity.

compiler-guy• 3 months ago

One of the things that makes jj worth trying out is simply the fact that it is different than git, and having exposure to more than one way of doing things is a good thing.

Even if you don't adopt it (and I didn't), it's easy to think that "this way is the only way", and seeing how systems other than your own preferred one manage workflows and issues is very useful for perspective.

That doesn't mean you should try everything regardless (we all only have so much time), but part of being a good engineer is understanding the options and tradeoffs, even of well loved and totally functional workflows.

beanjuiceII• 3 months ago

being a good engineer is also understanding when something is a waste of time because the gain is insignificant 99% of the time

eddd-ddde• 3 months ago

Using "good engineering" as an argument against learning is definitely an interesting approach.

dcre• 3 months ago

It seems like all of your comments are like this. Consider stopping that!

dwattttt2• 3 months ago

I think siblings point needs to be made more sharply: this could've gone somewhere good, "I evaluated it and found the gain was not worth the cost to change", but instead went to "the gain from a change is insignificant 99% of the time, so it's not worth understanding it".

The latter is poor engineering.

waynecochran• 3 months ago

Anything new or special in jj that allows me to work with large binary files simply? To me, this is still unsolved in terms of providing an elegant solution (e.g. things like Git Large File Storage (Git LFS) are awkward).

steveklabnik49• 3 months ago

Not yet. It's desired to do something better here, but there's no active development that I'm aware of right now.

(LFS support is in progress though)

brendoncarroll2• 3 months ago

I've heard that jj has support for non-git backends? Can anyone comment on how difficult it would be to add support for another backend, any docs or examples?

I have a project[0] that does the large file thing well, but is missing most of the version control porcelain. I've been looking for the path of least resistance to integrate it into something with a larger user base.

[0] https://github.com/gotvc/got

steveklabnik49• 3 months ago

To add a new backend, there's a trait that you implement for your backend: https://github.com/jj-vcs/jj/blob/713a0d0898448392d38fdcbaba...

I suspect if you came by the jj discord, folks could help you with more detail than that.

tobinfricke• 3 months ago

Here are some notes on Jujutsu from Evan Martin that I found interesting/useful:

https://neugierig.org/software/blog/2025/08/jj-bookmarks.htm...

misnome2• 3 months ago

The problems with jj that led me to abandon are:

- All of everything good about it breaks down the instant you want to share work with the outside world. It's git on the backend! Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match. And in doing so, you lose almost everything that gives it value in the first place - the elegant multi branch handling, anonymous commits, the evolog. Even if you want to work on the same project on two machines your only choice for this is without breaking everything via git is to rsync the folder. Yes, you can write alias to do all this like git. I might as well use git if I can't use the nice features.

- All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder. And then there is no way to ensure that it's purged (unlike in git) - the community response as far as I can tell is "Don't do this, never put a file that isn't in gitignore".

- And adding to .gitignore fails if you ever want to wind back in history - if you go back before a file was added to .gitignore, then whoops now it isn't ignored, is all part of your immutable history, and disappears if you ever switch off of that new commit state.

rstuart41339• 3 months ago

Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match.

All true. I ended up writing my own `jj push` and `jj pull` aliases that automated all this. They aren't simple aliases, but it worked. `jj push` for example "feels" very like `git push --force-with-lease`, except if you've stacked PR's it pushed all branches your on. It hasn't been a problem since.

I ended up wondering if they deliberately left the `jj pull` and `jj push` commands unimplemented just so you could write something custom.

All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder.

    jj abandon COMMIT && jj git garbage-collect

> And adding to .gitignore fails if you ever want to wind back in history - if you go back before a file was added to .gitignore, then whoops now it isn't ignored

True, but how is this different to any other VCS?

misnome2• 3 months ago

True, but how is this different to any other VCS?

What other VCS behaves this way by standard? If it's not in e.g. .gitignore "git status" will show that it's aware of it, but won't automatically absorb them into the commit? https://github.com/jj-vcs/jj/issues/5596 doesn't seem to be the oldest instance of this problem, but does seem to be the current discussion, and there seems to be no consensus on how to fix.

Oh, and ISTR submodules were a pain to work with.

Edit: https://github.com/jj-vcs/jj/issues/323#issuecomment-1129016... seems likely to be the earliest mention of this problem

pheggs• 3 months ago

I was already pretty happy with svn to be honest, I dont see myself switching away from the industry standard today for no substantial reason. in my opinion git was only able to change the standard thanks to github and a popular author (i love git and its branching, but I dont think it would have been enough if it was just for that). I personally believe its going to be very difficult for jj to replicate that.

newsoftheday5• 3 months ago

I like the distributed nature of git but miss how svn worked to some degree. Generally I agree with you, git works, I read the post and didn't see anything that makes me want to change. The small number of jjites who have been inundating comment sections on this site lately feels like the devotees of Rust (a crap language), podman (which has too many operational inconsistencies) and JetBrains IntelliJ ballywhooers who used to preach IntelliJ's features on every programming related site.

GuB-42• 3 months ago

In my opinion, svn lost to git because git is just so much better in a distributed environment. To me the improvement between git and svn is much more than the improvement between svn and cvs. In fact, by many aspects, I preferred cvs, but now that we have git, they can both go to hell.

Now, it is not the only DVCS, there is also Mercurial, which is built on similar principles. It could have become the standard, but I agree with you that the reason it didn't probably has to do with Github and Linux.

jj isn't fundamentally different from git, it is actually compatible with git, which is a good and a bad thing. Good because it makes transition easy, bad because it is fundamentally the same thing and there is no pressing reason to change.

But jj definitely look nicer than git, which is not hard, under the hood, git is great, but it is ugly. It started off as a hack and it still shows. I think the common sentiment of "I know git, I don't want to learn a new VCS" mostly tells about how painful the process of learning git was. If you had started off with Mercurial, like I did, I am sure it would feel much smoother, it is just git that is messy. For jj, it looks like they took the best parts of git and mercurial, so hopefully, the transition will be rather painless.

kristo• 3 months ago

I followed steve's excellent tutorial about two months ago, and haven't looked back. I have never felt so competent at git (vcs rather) as I do now. jj is so much simpler and easier for me to reason about.

tracker1• 3 months ago

Seems interesting, but tbf, I only really use a small subset of git commands as it is... I've tended to practice a few workflows that just reduce the overhead and risk for conflicts.

bikelang3• 3 months ago

Reading threads like this and the GitHub stacked PRs just makes me feel like an alien. Am I the only one that thinks that commits are a pointless unit of change?

To me - the PR is the product of output I care about. The discussion in the review is infinitely more important than a description of a single change in a whole series of changes. At no point are we going to ship a partial piece of my work - we’re going to ship the result of the PR once accepted.

I just squash merge everything now. When I do git archeology - I get a nice link to the PR and I can see the entire set of changes it introduced with the full context. A commit - at best - lets me undo some change while I’m actively developing. But even then it’s often easier to just change the code back and commit that.

steveklabnik49• 3 months ago

You're not an alien: this is the workflow that GitHub encourages.

It's just that not every tool is GitHub. Other systems, like Gerrit, don't use the PR as the unit of change: they use the commit itself. And you do regularly ship individual commits. Instead of squashing at the end, you squash during development.

bikelang3• 3 months ago

Thanks for explaining that. Having a bit of a (dim) lightbulb moment now. I’ve never used Gerrit - just GitHub and GitLab and Forgejo. So I assumed the PR/MR model was more or less universal. But if smaller development commits are being squashed into the shippable/reviewable unit - then the focus on commits makes a lot more sense.

rs5458373• 3 months ago

You could agree that the PR is the meaningful unit for shipping, but push back gently that for agents working in parallel, the commit/changeset level matters more than it used to because agents don't coordinate the way humans do. Multiple agents touching the same repo need finer-grained units of change than "the whole PR."

bikelang3• 3 months ago

Could you elaborate a bit more on this? Curious what your workflow looks like. Is this multiple agents running on the same feature/refactor/whatever unit of work? For concurrent but divergent work I just use a git worktree per feature. And I think I only ever have a single agent (with whatever subagents it spins up) per unit of work.

ai_slop_hater• 3 months ago

Unfortunately OpenAI's models really suck at JJ, while, on the other hand, Opus 4.6 is much better at it, probably due to a later training cut off.

Aperocky3• 3 months ago

With agents, my go to is now have multiple of the same repository and each agents must work on a separate one.

Preventing dirty workspace by solving the co-work problem to start with. merges are much more trivial than trying to make agents remember which branch or which folder it is supposed to work on. Disk space is cheaper than mental anguish and token usage.

rattray2• 3 months ago

What's your naming scheme?

Aperocky3• 3 months ago

REPO_NAME_0

REPO_NAME_1

REPO_NAME_2

REPO_NAME_3

chriswarbo5• 3 months ago

https://git-scm.com/docs/git-worktree

Aperocky3• 3 months ago

rare case of feature bloat for git. Still completely optional, thank god linus.

rattray2• 3 months ago

Has anyone tried both jj and gitbutler extensively yet? Both seem to have some interesting new ideas on top of git.

ymir_e• 3 months ago

I was hoping someone else had written about it here.

From my knowledge there are three different takes on git being worked on which looked interesting. - JJ - GitButler - Zed

Zed version system doesn't have that much public info yet, but they wanted to build a db for storing code versions for AI agents. Not sure if this is still the direction, and I'm a bit skeptical, but interested to see what they come up with.

Even though git works well enough, I'm certain there will be another preferred way at some point in the future. There are aspects of git that are simply not intuitive, and the CLI itself is not up to standard of today's DX.

newsoftheday5• 3 months ago

OK I read it, I'm not interested, git does exactly what I want.

tombert• 3 months ago

That's sort of where I've been stuck with with jj.

Maybe someone can convince me otherwise, but to me it hasn't felt sufficiently better than git to justify bothering re-learning this stuff, even if it's relatively easy.

plutokras• 3 months ago

Git wins by not needing to be replaced badly enough. Latley you can just ask an agent to "amend the last commit" so even that is being abstracted away.

sam_goody• 3 months ago

I use the CLI often enough, but still most of my time is in a GUI. It just makes the diffs easier, the flow simpler, etc.

As such, I wanted to break into jj via the GUI, and only adopt the command line after I could visualize the concepts and differences in my head.

Alas, the GUI I tried - a VSCode plugin - did more to confuse me than to help, and it made it very easy to catastrophically rewrite the history by accident. I tried another UI and it kept failing and leaving me with cleanup work. I couldn't find a third UI that looked promising.

So, I gave up. One less jj user on the planet - no biggie. But I really wonder if it would be worth the effort for some of the jj pushers to try to get a proper UI in place - I bet I am not the only one that likes to learn visually.

carverauto• 3 months ago

am a big fan, just started using it a few days ago

jtrueb• 3 months ago

Call me crazy, but jj is more confusing than git.

jancsika• 3 months ago

I was going to write a big long comment, but honestly it boils down to this:

Whatever git's practical benefits over SVN and CVS back in the day (and I can go into the weeds as a user if someone wants that), git was the DVCS that took over from the centralized VCS's of that era.

There is nothing in jj, pijul, or Bram Cohen's thing that is anywhere near as dramatic a quality of life improvement as going from VCS to any DVCS. And dramatic improvement is what is needed to unseat git as the standard DVCS.

I mean, if you're not doing something so important[1] that it adds a letter to the acronym, it's probably not the next new thing in version control.

1: I originally wrote the word "novel" here. But it has to be big-- something like guaranteeing supply chain integrity. (No clue if a DVCS can even do that, but that's the level of capability that's needed for people to even consider switching from git to something else.)

rstuart41339• 3 months ago

There is some truth to that, but to give a different perspective ...

A long, long time ago, back when VCS's were novel enough to be of academic interest, I read numerous papers describing what these VCS's could be. They talked in terms of change sets, and applying them like a calculus to source code. In the meantime those of us writing code people actually used were using sccs and rcs, or if you were really unlucky Visual SourceSafe. To us in the trenches those academics were dreamers in ivory towers.

With the passage of time we got new VCS that gradually knocked the rough edges off thoase early ones. svn gave us atomic commits, hg gave us a distributed VCS, git gave us that plus speed. But none came close to realising the dreams of those early academics. It seemed like it was an impossible dream. But then along came jj ... and those dreams were realised.

acoustics• 3 months ago

jj has made me much more comfortable using non-linear DAGs in my trunk-based development workflow. Several changes with the same parent, changes with several different parents, etc.

I used to have a habit of imposing an unnecessary ordering structure on my work product. My stack of changes would look like A -> B -> C -> D, even if the order of B and C was logically interchangeable.

jj makes DAGs easier to work with because of how it handles conflicts and merges. Now I feel empowered to be more expressive and accurate about what a change actually depends on. In turn, this makes review and submission more efficient.

tonfa3• 3 months ago

Do you use a mega-merge + absorb workflow on top of the faned-out changes?

eranation• 3 months ago

For those who switched, what is the main selling point that made you stay with Jujutsu?

tonfa3• 3 months ago

For me, can do anything complex in terms of history rewriting without ever shooting myself in the foot (worse case just `jj undo`).

And the UI is pretty intuitive so don't really have to search for a solution, usually the command to use is obvious (tho I guess now you could delegate the UI to an LLM to ask it to give you the right incantations).

0xnadr• 3 months ago

Interesting to see more Rust CLI tools gaining traction. The undo-everything model is compelling. I've lost work to bad git rebases more times than I'd like to admit.

TrysterosEmp• 3 months ago

Why should you care about jj? Look, ethereal, balaeric Gothenburg indie from the 2010s may not be important in the grand scheme of things, but their strong hip hop influence was genuinely exciting at the time. When the great chill wave summer of 2009 crested, you definitely cared about jj’s otherworldly grooves and lil Wayne samples. Even if they never did reach the euphoric highs of Washed Out or even label mates The Tough Alliance.

erdaniels• 3 months ago

Preach... thank you

dmitshur2• 3 months ago

What is the current story for serving jj repositories over HTTPS? Git has https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protoco... . Does jj have something better, equivalent, or nothing (at this time) at all?

steveklabnik49• 3 months ago

Unless you're at Google (or writing your own backend), jj talks to a git server, and so you'd just do exactly that: host a git repo over https.

dmitshur2• 3 months ago

I am at Google, but that's probably not relevant since the reason I was curious about this is that my personal website currently implements a git server over HTTPS[1], and git's CLI/API for that is not the friendliest[2]. It sounds like jj hasn't reached the point of tackling this problem space yet, which is okay. Thanks for confirming I wasn't missing out on something.

[1] https://pkg.go.dev/github.com/shurcooL/home/internal/code#Ne...

[2] https://pkg.go.dev/github.com/shurcooL/home/cmd/githook/pre-...

ibejoeb2• 3 months ago

A lot of the discussion focuses on differences from git and how it uses the git storage strategy under the hood. Honestly, I think you should just ignore all of that. Don't think about git. Here's a workflow that'll get you through your daily usage:

On a clean repo:

    $ jj
    The working copy has no changes.
    Working copy  (@) : abcdef a53ff9ba (empty) (no description set)
    Parent commit (@-): qrstuv 4bc1bf34 the last thing you did

Make some changes.

    $ jj # shows status (new, modified, deleted, moved, etc.)

If you're satisfied with your changes,

    $ jj commit -m "made changes"

Now `jj` is back to clean state. You don't need to do `jj new` to continue working linearly. Just make your next changes and commit. If you realize that you messed something up, fix it, then `jj squash` and it gets incorporated into that last commit.

You only `jj new -r lmnop` if you want to do some work based on the state of the codebase at revision lmnop, rather than the previous revision, which is a figurative branch. No need to manually create and name branches.

As for git history: just do `git log` to see what's actually going on. It's a clean history reflecting your `jj commit`s. You're not going to see all of the stuff the jj machinery does.

skydhash6• 3 months ago

If I really wanted that, I could create an alias like

  alias.save="!git add -A; git commit -m"

And then use

  $ git save "made changes"

ibejoeb2• 3 months ago

You could. That's not the point. I suggesting that if you want to try jj, try it based on its affordances, not by comparing it to how you'd do it differently with git.

Most of the tutorials start with git and try to teach you how to change your thinking. I think the project would find many more fans if it didn't make such a big deal about being kinda like git.

8n4vidtmkvmk• 3 months ago

Sometimes i like to jj describe before writing any code. It helps with mental clarity what i intend on writing or helps if i have to run away mid coding session (description will show in log so i can find it again)

In this scenario I'd instead jj new at the end, after im finished and ready to move on to the next thing.

MrGreenTea• 3 months ago

You can then also just use `jj commit`. It will see the existing commit message and just move to a new clean revision.

busfahrer2• 3 months ago

Don't think about git.

You can also make the reverse point, only think about git:

In theory it's perfectly possible if you have to jj binary lying around somewhere, to not even use it as your git client, but to temporarily do a `jj git init --colocate`, do a complex restructuring of your repo across 3 branches, and then delete the .jj folder again :-)

Just to highlight the other end of the spectrum, jj is flexible like that

steveklabnik49• 3 months ago

Colocation is the default these days, so you don't even need that flag :)

lofaszvanitt• 3 months ago

Someone add attribute and rights handling to git. Plus empty dirs. And thats all.

LoganDark• 3 months ago

I tried jj and holy wow it's so perfect for me. There's a learning curve but I picked a bunch of it up within a couple hours and I am going to be pretty much using only jj from now on.

aubanel• 3 months ago

Does jj work well with parallel agents?

The current problem that I often have is that I want to work on several things in parallel through several agents, always forget to do worktrees, then the different branches of work tend to step on each other Does JJ make it simpler?

hi-im-buggy2• 3 months ago

jj supports workspaces, akin to git's worktrees. They've felt pretty natural for me to use.

The only caveat is that if you're in jj repo that uses git colocation, only your main workspace will have a `.git/` directory. When you have other infra set up that assumes you're in a valid git repo, this can be a little annoying.

hi-im-buggy2• 3 months ago

jj's mental model maps really well to Gerrit's code review system. It's also really nice to have `jj undo` and automatic rebasing.

CodeCompost• 3 months ago

I like the idea but it feels like more of an attempt to usurp Git than actually solving a problem.

jj – the CLI for Jujutsu

Related Stories