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.

> 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.

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.

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.

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.

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.

> 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.

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.

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.

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.

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

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.

> 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. =)

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

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.