I made a mess of a jj repo recently. A big mess. Ran `jj op log`, found the operation I wanted, and just `jj restore`d my way back to that exact prior state. Then started what I was planning afresh and got it right. Felt magical.

And I didn't have to learn anything like the hell of git refs. The UI is self-explanatory as long as you know the feature exists.

Another very nice thing is that conflicts aren't roadblocks. They're legit changes, first-class jj citizens. So, when I do something that ends in a conflict, I can just move over to a different change, do the work I'm already trying to do, and then go back and resolve the conflict when I want.

Ah yes, I’ve heard it makes the hell of huge conflict ridden rebases a bit less annoying. Always wished I could just get to the end of the rebase to see it all in context, _then_ resolve conflicts, but with the option to resolve the obvious ones along the way too.

Yep, this was the thing that encouraged me to look at jj. I am so done with rebases where I’m stuck in some meta-state where I need to figure out exactly what needs to be done—linearly, right now, and without making any mistakes—but all the regular tooling to jump around and explore is unavailable until I’m finished with the whole thing.

I would honestly use jj for just this even if that was all it offered.

I hear ya. I've done some crazy things with `git reflog` (which I always pronounce git re-flog instead of ref-log) but it is not fun.

There's the usual cognitive shift, and in my case a bit of a best-practice shift I had to go through to get comfortable with `jj` -- specifically, keeping the repo directory pristine (and putting my temp output in a git-ignored dir, or outside the repo) because /everything/ is tracked. Flip side being, I've forgotten to `git add` new files at least a few times a year, and now that won't be an issue.

But yeah, can highly recommend, and I'm excited to start to jump between multiple open branches^Wbookmarks at will and learn more about the intricacies of conflict management (and the original link is a good glimpse at that!)

Are new files tracked by default? If I forget to ignore a bunch of build outputs, will that make my repo huge immediately?

There’s a configurable cap on max file size to auto-add, IIRC. It defaults to something “reasonable”.

If you do somehow add a terabyte of small files by accident, it’s still just git under the hood so you can make sure nothing active points at them and GC them.

I'm thinking of something like node_modules, sounds like I'll need to not forget.

Those are usually in your gitignore, right?

Also, this behavior (automatically tracking) is configurable. I thought I would hate it but I actually really like it.

Yeah they usually are, I'm sure it's great because I add files more often than I ignore, but I need to be careful with the temporary files I write left and right in the repo dir during development.

Why? You can easily remove them if they’re accidentally added.

Just because I might not remember/notice, and I don't want sensitive data to be committed by accident if I put an env var on disk for some reason.

If you check `jj status` regularly and/or use `jj split` to build up your commits (like `git add -p`) then you’ll notice. They might end up in your local repo (until a gc) at worst.

Ah, that's not too bad then, thank you!