The only thing that changed in the two things you wrote was `ranch` -> `cdef`. Every other part of that PS1 output was the same.
Now put yourself in the shoes of a git novice and ask yourself if you'd always notice the difference. At least from my experience, they often don't, especially if they're concentrating on something else, it if they're using an IDE and the visual information about which branch/commit is checked out.
I don't think you're crazy, I think you're just too used to this sort of stuff to remember what it was like to still be learning git. When I say people make these sorts of mistakes, I'm thinking about real colleagues of mine who have made exactly these mistakes and then panicked that commits suddenly had disappeared.
Similarly, I think to you, unnamed branches feel like something complicated because in git that are. Git makes it very easy for commits to seemingly disappear into the ether, even though they are still there. But in jj, they don't disappear - they remain very visible, and the log UI shows them in a way that makes it clear where they come from. The default log UI is something like git's --graph output, which means you see how the different commits interact with each other. I really recommend having a look at the output of `jj log`, because I think then it'll be a lot clearer what I mean when I say that it's not hard to figure out what the right commit is.
I missed the formatting on my original comment, but to use real commit names:
fragmede@laptop:(main)~/projects/project-foo$
fragmede@laptop:(cf95b5ac22fd...)~/projects/project-foo$
fragmede@laptop:(opengl_meters)~/projects/project-foo$
Is the difference between these 3 really that subtle? How do you miss that the line lengths are different and that one of them is a pile of letters and the other is a word? I'm not trying to die on some "git is easy to use" hill because it isn't. Just that the difference between unnamed branches and named branches isn't this hidden undiscoverable thing. I don't have access to this dataset of Mr Klabnik's, but apparently it is.I don't know how much it matters in AI-codepocalypse because I'll be honest, I haven't used git manually in days. AI writes my commit messages and deals with that shit now. (Claude ends a session with "Want me to push it?" and I just reply "yes".
> Similarly, I think to you, unnamed branches feel like something complicated because in git they are.
It's not that working with unnamed branches in git seems complicated, it's that it seems opposite to how I, and by extension, other people work. Now, obviously that assumption of mine doesn't hold true, otherwise we wouldn't be having this discussion, but going back to my Google docs example, staring at a page of documents called Untitled document isn't helpful, so in my mind, there's just a bit of digital hygiene that's necessary under any system.
> I really recommend having a look at the output of `jj log`, because I think then it'll be a lot clearer what I mean when I say that it's not hard to figure out what the right commit is.
You tell me which commit I want from this `jj log` output:
@ nlvqqyzv [email protected] 2026-04-15 04:43:07 0d644b5d
│ (empty) (no description set)
│ ○ nkuswmkt [email protected] 2026-04-15 04:43:07 e071e1a5
├─╯ (no description set)
○ ytyvtmpr [email protected] 2026-04-15 04:42:51 bd5b4717
│ (no description set)
│ ○ srmtuszo [email protected] 2026-04-15 04:42:35 aa64aea2
├─╯ (no description set)
○ nrqwxvzl [email protected] 2026-04-15 04:40:42 c1dbbda3
│ (no description set)
The effort to label those with `jj describe` what "nrqwxvzl" is vs "nkuswmkt" could just as well be put into using named branches.Again, I'm not trying to die on a "git is easy to use" hill, because it isn't. My point was that "> these two states look completely identical" isn't true if you setup PS1 to tell you what state you're in.
jj gets a lot of things right, there's no panicking that work got lost. That is a big deal! The emotion toll that the possibility of that happening with git causes on new users is hard to understate. It's hard to not be scared of git after you've lost hours of work after running the wrong command.
I didn't raise $17m to build what comes after git, although I've thought a lot about that problem. Improvements in that area are welcome, and the easier it is for people to work with stacked change sets and branches, globally, can only be a good thing. I can't make everyone else get as good at git as I am (or better!), so I welcome better tooling.
> Now put yourself in the shoes of a git novice
Sometimes it seems to me that's only in SWE we allow people to proceed in the workplace without any training. There's enough learning material that people should take a week or something to practice git and not be git novice anymore.