[cobyte8]

> using jj was like riding a bike

This has been my experience as well! I haven't had success conveying that to my peers at work (or outside), but your comment resonates with me deeply.

> If you forget to start a new rev before you (or your LLM) touch the repo, it's a little bit of a pain to go back and split the changes into a new rev.

This is one area where I broke my Fig habits and just switched to a the [Squash workflow](https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...): I basically forbid myself from use `jj edit` and have been pretty successful in getting that to stick in my brain. Instead, I use `jj new` to switch contexts (and then `jj commit`, `jj squash`, or `jj absorb` depending on what I'm trying to achieve).

> Some of the more mature repos I've worked with have tooling/scripts/tests/etc. that seem to look for or rely on the presence of .git (perhaps indirectly).

Yeah, I've noticed this too. I find that the most common root cause is usually something that wants to run a lint tool only against the files that you've changed so it does something to the effect of `git diff --name-only $(git merge-base HEAD origin/main)`. I've also noticed that some precommit hooks have been working better since I enabled the `git.subprocess` option (which is on by default as of recently, I believe).

[endtime]

I have more or less been using the squash workflow, but nevertheless, remembering to do `jj new` before doing anything else is a challenge. Might just get used to it with more time.

[cobyte8]

Hmm, maybe I'm missing something, but you can use the squash workflow so that you don't have to remember to start a new commit: you're always at an empty commit when you context switch to repo.

* If you `git clone ...` and then `jj git init --colocate`, you're in a new commit (whose parent is the HEAD of the git repo).

* If you write some code and then `jj commit`, you're now in a new commit.

* If you want to work on top of commit zyx instead, you can run `jj new zyx` (not `jj edit zyx && jj new`).

* If you're done for the day, you can `jj commit -m "temp: it kinda works, I'll take another stab tomorrow"` and you're on a new commit again.

In many ways, this reflects the normal git workflow (if you want something checkpointed, you've "commit"ed it). This does mean that while I'm in the middle of working on something, I have some commits that aren't split by logic but by chronology. So instead of one commit ("make foo"), I'll have three commits ("try to make foo", "eh, didn't work, try again", "fix bar so that foo actually works now") that reflect my process rather than logic. Once I'm convinced that I finally did it right, jj makes it easy to squash/manipulate the commits into the logical units I want to present in my PR (or record in my history for personal projects).