Ok, so I have to admit I started skimming soon, because after explanation of `jj new`, I thought this is just `git commit --allow-empty`. Oh, and you can specify the message! Add `-m` and you are done.

Then it's a series of either git ammends or `git checkout -b` etc.

Now, since there is so much high praise in this comment and sibling comments, what am I really missing? From the post it just seems like the person hates branches for an unspecified reason.

Here's my workflow, of the past 15 years:

- git checkout main - git pull

Do some changes. Do some more changes. Now:

- git checkout -b <feature-name> - git status - gvim into every file and then :Gvdiffsplit, select what I want to stage for each file - git push # open PR if I think it's ready

For the remaining changes not in the commit, I either create a separate commit, or discard.

An honest question of curiosity, how does jj improve this workflow?

Here's a few workflows that I really enjoy in jj:

- While I'm working on something I can do `jj desc` and start writing the commit message. Every edit is automatically being added to this change.

- My work tree is dirty and I quickly want to switch to a clean slate. In Git: (1) either do `git stash` where I'm definitely is going to forget about it or (2) do `git commit -a -m wip && git switch -c some-random-branch-name`. In jj: `jj new @-`. That's it! If I run `jj log` then my previous change shows up. No need to come up with arbitrary names. It's so refreshing to move changes around.

- I'm working on a stack of changes and sometimes need to make edits to different parts. In Git (1): Each change is its own branch and I need to switch around and do a bunch of rebases to keep them in sync. In Git (2): I have one branch with multiple commits. I make changes towards the final state and then do `git rebase -i` to move them upwards to where they belong. Biggest downside: I'm not actually testing the changes at the point where they end up and I'm not guaranteed it makes sense. In jj: I do `jj new <CHANGE>` to make changes further up in the stack. Once I'm happy with it I do `jj squash` and every dependent change is automatically rebased on top.

- And finally: I can solve merge conflicts when I want to! If any rebasing leads to a merge conflict I don't have to deal with it right away.

That exact workflow? It won't improve much. But it tends to change peoples' workflows.

For example: let's say you have a few feature branches in flight at the same time, and you want to make a change to one of them to address some PR feedback. In your git workflow, that presumably means something like `git stash; git checkout feature-name; vim-and-actually-make-the-change; git add -up; git commit; git push; git checkout whatever-you-were-doing-before; git stash pop`, ± a `--amend` depending on your PR philosophy. A common workflow in jj is to instead sit on top of a merge commit with all the feature branches at once, and handle this like `vim-and-actually-make-the-change; jj squash -i --into feature-name; jj git push`. You can do something like the latter in git too, of course, it just tends to get hairy relatively quickly with rebases and merge conflicts.

If you already have 15 years of muscle memory for efficient use of git it's probably not that valuable to you. AFAIU jj's goal is to allow people to be as effective in a workflow like you describe without having to stumble through all of git to find the happy path building that muscle memory.

I have a similar workflow with jj.

jj will start recording all of your changes as a real commit that it constantly rewrites as you edit files. You can write the log message for it up front or later. Think of it as an index that every change automatically gets staged to, except it’s just a commit, so instead of two concepts that work differently, you just have one. And you get the benefits of real commits, so for instance you can’t accidentally lose anything you staged that isn’t committed.

When you would create a branch and then stage changes with Git, what you would do in jj is split. The changes you don’t pick end up as the next auto-updating commit, and the changes you do pick use the log message you already set when you were working on them. So if you’ve got a bunch of changes you want to record as a series of commits, you just split however many times you want.

You don’t have to think about branching while you are doing this. The HEAD of master doesn’t automatically move when you are making these changes, so the effect is that you’re working on an anonymous branch already without having to create one. You can give it a name whenever you want by setting a bookmark. Or if you decide that the changes you make need to go into two branches, then you can add two bookmarks.

For instance, if you have:

A (master) => [changes]

Then [changes] is already a commit. Suppose you realise that you have fixed a bug and added a feature, but you want these as separate pull requests. You’d split, giving the bug fix a log message:

A (master) => B (bug fix) => [changes]

Then you’d give the feature a log message:

A (master) => B (bug fix) => C (feature)

Even though we started on master and made a bunch of commits without even thinking about branches, we haven’t changed master at all. So in effect, it’s like B and C are on some anonymous branch that was transparently created for you.

Now you want to open the pull requests, so you add a bookmark for B and a bookmark for C, and push them to your remote. B and C show up as branches that you can open pull requests for.

So your workflow is basically the same as it is now, there’s just fewer moving parts for you to think about as you work, and fewer concepts for newbies to learn.

It may not make it fundamentally better, but it might make it easier and more pleasant. That’s what jj does for me; my basic workflow would work in git too, but it’s just nicer and easier. Which I would not have guessed, as I was very comfortable with git before I switched.

In your case, jj’s ability to slice and dice commits is really nice; jj split is built in and works similarly, but you also have other tools too.