they might be stored as deltas against other objects

And explicitly not necessarily as deltas against the parent commit or the same file in a different commit at all.

Kudos, well said.

It’s a bit ironic, I’ve tried jujutsu before (when it was probably a bit less stable) and somehow couldn’t wrap my head around it that well. Went back to git almost immediately. I think your comment about not thinking about current changes just made it “click” a bit for me :) I’ve long ago started telling other people how bad the git interface is and somehow I wanted jj to just be a better UI, when it is a (hopefully) better workflow - with a better UI. I gonna have to give it another go down the road…

Never having to think about git stash ever again is so empowering.

That sounds incredible. One of the worst parts about git is managing worktrees, or stashes, or multiple repo copies entirely (for when things get really hairy or critical).

IMO (as a helix/typst/jj user) the apt right-hand for bash is fish. It has a simplifying-yet-empowering feel to me very similar to how jj does about git; feeling very confident with a uniform shell (particularly re: variables, escaping, functions, the range of built-ins) is a really nice feeling that’d escaped me forever, too.

Have you tried fish yet? I’ve found it pretty close to that for me

One thing I’ve come to realize makes shell/bash hard is that it is a grab bag of state, and there are all these inconsistent commands to inspect that state, like:

Print global options:

$ set -o |head -n 2
allexport       off
braceexpand     on

Print variables and functions:

$ set  |head -n 2
AGENT_VARS_FILE=/home/andy/.ssh/agent-vars.sh
BASH=/bin/bash

Do you want to figure out if a variable is an environment variable (exported), or read-only?

$ declare -p |head -n 2
declare -r AGENT_VARS_FILE="/home/andy/.ssh/agent-vars.sh"
declare -- BASH="/bin/bash"

Another way to print functions

$ declare -f u
u () 
{ 
    cd ..
}

What about external commands and builtins? (there doesn’t appear to be a way to enumerate all of them)

$ type -a true
true is a shell builtin
true is /usr/bin/true
true is /bin/true

aliases:

$ alias -p | head -n 2
alias gitd='git diff'
alias grep='grep --color=auto'

There are also

• traps with trap -p
• these magic variables like $PS1 $RANDOM $HOME which live in the same namespace.
  • the variables behave differently – some of them are for configuration, and some like LANG= even make system calls!

So yeah all of that is hard to remember. And the syntax doesn’t correspond with the semantics

I definitely didn’t know it before working on Oils

The upcoming Oils release organizes a lot of this into a single object model / namespaces, so you can inspect the state of the shell with a single command.

The idea is to make it more like Python, where you can use dir() and getattr() on anything, and kinda navigate the state of the interpreter, without reading the manual.

A big part of that is pretty printing, with the = operator ;-)

ysh-0.24.0$ = {k: 42}
(Dict)  {k: 42}

ysh-0.24.0$ proc p { echo hi }
ysh-0.24.0$ = p
<Proc 0xb50>

You should be able to pretty print the entire state of the shell uniformly, as well as choosing which parts to print.

But we’re not done with this – it may take awhile to put everything in namespaces and make it uniform, with reflection.

It’s also true there are other parts of bash/shell to learn, like there are essentially 5 different process constructs:

• ls - external
• ls | wc -l - pipelines are very special cases
• ( subshell ) - people confuse this syntax for grouping
• background & - somewhat weird syntax
• $(date) - command sub

(and bash also has process sub). YSH also rationalizes those a bit

I call those “exterior” constructs and the latter “interior”

One thing I’ve also noticed confuses people is that ls is external, but cd is internal, but there is no syntactic difference. It is not very visible or discoverable

There are two settings (diff-editor and merge-editor), and when I set them both to vscode I eventually ended up in some state where the editor was confused showing empty temporary files. Unfortunately I wasn’t sure what I was doing so I’m not sure how to reconstruct it.

jj new always creates a new change. The arguments you pass determine where this change is created:

• no arguments: on top of @
• with an argument: on top of that change
• with multiple arguments: on top of all of those changes, aka, a merge

They’re not wildly different: it’s always “create a new change.” The arguments control which parents this new changes has, but that’s it.

You’re not wrong that from a git perspective this could involve multiple commands, but that’s because git has more concepts than jj does, and so needs more commands to express the same things.

I think the idea behind removing ‘git convenience’ aliases is to guide the user into the proper mental model. All those invocations of new are identical (Well, the first is short for jj new @). It creates a new change with the specified parents. I do think that unifying ‘normal’ and ‘merge’ commits into one kind of object is a useful simplification.

Personally I think building this simpler mental model is valuable. I can do basically everything I can imagine doing with a git history with 3 commands: jj new, jj rebase, jj squash.

I felt the same way when I first tried it, but I now think my sibling comment is right.

In the post I mentioned that thinking about things in terms of “what this does in Git” ends up making things harder to understand, much as if you tried to learn Git in terms of what each command does in svn.

I think the key difference is, in jj these are the one command because they are actually the one operation in terms of its model, and that model turns out to be very easy to reason about.

I think a lot of this is to do with the mental model. In Git, a branch is a real thing - you can check out a branch that points to a commit, and you can check out a commit, and these are two different things that result in different states and will produce different effects when you try and commit or make further changes. Therefore, the CLI needs to differentiate these things for clarity, including using different commands.

In Jujutsu, though, a commit is a commit is a commit. A bookmark is nothing more than a link to a commit with some associated metadata about upstreams. And jj new creates a new commit that follows on from the commit(s) that you pass it. It doesn’t matter if you give it that commit as a bookmark, as a commit ID, as a relative commit, or even as a git hash - as long as it can uniquely identify a commit, it can create a new commit based off that and check it out. Even jj new by itself is doing the same thing, but with the implicit argument of “the current commit” (i.e. create a new commit with the parent as the current commit).

The merge version is possibly a bit cleverer - I’ve not actually used it like that before, as I mostly merge via Github/lab/etc, and rebase locally. In principle it’s doing the same thing, but with multiple commits instead of one. But I’m more used to a merge commit being its own thing, so it feels a bit funky to create a new commit from multiple commits like that.

This is more of a problem with reconciling fundamental differences in the Git/Mercurial vs jj workflows.

Of course, jj new is only responsible for creating a new commit (and materializing it in the working copy by default). The problem is that when you’re trying to imitate the Git/Mercurial workflows, then you end up creating a bunch of new commits to represent the staging area and/or working copy, so it seems like jj new is doing everything.

An alternative “edit workflow”, used by many, might have these equivalencies for your cases:

• git commit -> jj describe
• git switch -> jj edit
• git merge -> jj new

However, the edit workflow distinguishes between ‘starting’ and ‘finishing’ work in a way that Git/Mercurial don’t, so it’s not a perfect equivalence.

For use with github, the idea is to create multiple stacked PRs, same as graphite does. However, the forge integrations in jj are still WIP, so people either do it manually, use a script, or some external tooling for now.

A common flow is to jj new COMMIT (which puts you on a new commit descending from COMMIT). You can squash changes back into the parent interactively, which means you’ve essentially DIYed your own “index”. Except, if you instead decide you want this set of working changes to be its own commit, you can just leave it in the new one. Maybe you then rebase this commit (e.g. jj rebase -r @ -B xyz where xyz is the commit following your target in the main line), to put this as a new commit in after. Or whatever, you can throw it around anywhere, squash it, leave it. The unit is a commit.

edit to add: also, you can just jj op undo if something didn’t work! All snapshots are saved, so you can rewind to any point you ran any jj command, including just status, etc.

edit to elaborate: those local changes, then, would be on their own commit. You wouldn’t accidentally push it, because it’s clearly a WIP commit. You probably haven’t given it its final description yet, there’s other random stuff in there you don’t intend to push. Bookmarks (for git tracking purposes) don’t get moved automatically; you explicitly do it. It turns out this works well.

One thing I didn’t learn until using jj in anger on a shared repo with lots of branches and frequent committers, is that leaf commits (w/o an associated bookmark) are automatically ‘suspect’ in jj, because you don’t only “checkout a branch” — you jj new cool-branch@origin instead. You’re now on an empty commit (and the UI marks empty commits in many places for good reason), and if you move off it without making any changes, it automatically vanishes (gets abandoned).

If you happen to make some local changes first, maybe you play around with something, then those are of course saved in that new commit until you explicitly drop them. If you check something else out and then want to return, unlike git I don’t look at the branch list, I jj log and it shows everything relevant, including my leaf commit on top of a commit that has cool-branch@origin next to its ID. So I see it and go, right, there’s my old WIP or whatever, I’ll edit that, or new that, or whatever. If I later jj git fetch and that cool-branch@origin has moved, I’ll still see my old WIP commit poking out of the branch halfway, and I can rebase it on top of the new branch head and then edit it. (You can do it the other way around, like git, as well — edit it, and then rebase it — but isn’t it cool that the working copy truly isn’t privileged in this way? You don’t have to focus the Eye of Sauron on a commit to rebase it. Heck, you can rebase multiple disparate commits with a revset all at once.)

With git, I often mess around on old commits and then decide to abandon my attempt by using “git checkout” or “git rebase –abort” and know that I will get back to a pristine working copy of the upstream repo.

It’s interesting to note that Git doesn’t have a facility to undo that undo operation, while jj does:

• In Git, you can’t say “actually, I want to resume that rebase I started” and jump back directly into what you were doing.
• In jj, all of the intermediate rebase states are just commits, so there’s no secret extra state (like the .git/rebase-merge directory) that tracks the rebase.
• In jj, you can use jj undo to undo an arbitrary operation.

So jj should actually be safer once you get used to it.

Similarly, just doing “git checkout” to switch to a different branch I might have some local changes I forgot about. Having those implicitly auto-committed sounds rather dangerous to me. How does jj prevent accidentally pushing work-in-progress changes?

There are a few default mechanisms:

• When creating a new commit, jj won’t automatically “advance” the branch pointing to its parent commit. Many commits are therefore not addressable by branches by default, so you wouldn’t easily be able to accidentally push them.
• jj git push will refuse to push commits without a description, and jj new will create commits without descriptions by default.
• There’s the git.private-commits configuration setting to configure your own set of commits that shouldn’t be pushed.

By default, jj does a snapshot every time you run a jj command. However, you can configure it to use watchman, and it will then be able to snapshot based on file system changes.

Case A, you lose your edit. Case B, you don’t. It takes a snapshot of the working copy on every invocation. You’ll find mention of this in the docs in a few places, and can also configure this behavior.

I went through the same thought process about 6 months ago (i’ve been using jj exclusively since) and this part took no more than an hour or two to become muscle memory.