[danpalmer]

This is a pretty good summary of my experience and a small set of steps to understand to see why it's different – the idea that features of git are workflows/patterns in JJ is a nice one.

> it's kind of hard to convey how a few, smaller, more orthogonal primitives let you do everything you can do in git, but easier

Some of this didn't really click for me until I experienced it (and I'm still very much learning). The one that sticks out is how you're always in a commit. Where in git you work in "modes" – editing in the index, rebasing, committing, etc. In jj you're always "stable" and can do anything from that point.

The way this is sold is things like "mutable commits" or "first class conflicts", but for me the real power was just realising that I can always move to another commit/change without having to pre-plan how to do that, always being able to edit my commit message right now without having to finish up something else first. Now going back to git feels like the tool is slowing me down and not keeping up with the pace and style I want to work in. I was surprised that this was the thing I most enjoy, because it's a little hard to motivate.

[ljm]

I remember at an old job where the feedback loop was quite slow, so you always ended up with multiple branches or PRs in play at a time. I ended up using git worktree to basically have each branch as its own separate workspace (rip my hard drive) because the process of stashing and switching, pulling, and untangling wip commits got old fast.

I still juggle a few plates now (for better or worse) and especially with VisualJJ that experience is much nicer. I can just switch between bookmarks and do what I need to, and `absorb` makes that super nice in terms of addressing PR feedback.

[steveklabnik]

jj also has workspaces, which are the same as a git worktree, if you want that workflow.

[jmholla]

My biggest concern with moving to `jj` is how it handles new files. I don't always want files I create in my repository to end up on a remote and I have been under the impression `jj` assumes everything it hasn't been told to ignore is part of the repository.

[necauqua]

You can set `snapshot.auto-track` config to "none()" (which is a fileset, so you could actually have something like src/* there).

That way, only files that were already present in the wc commit are amended, and new files are kept untracked until you explicitly `jj file track` them. And jj status finally fully shows them in the main branch too (it's broken in the v0.26 release sadly)

[danpalmer]

I guess it depends on your workflow. If you stage each file carefully in git, it's effectively opt-in as you suggest. If you `git add .` though, as many people do out of habit, then it's not going to help much. The same is true really for jj, if you don't edit your commits then yeah, it'll be included by default, but if you craft your commits then you'll spot it.

Also jj doesn't push until you push your changes when backing on to git. This is pluggable though, the backend I work with is not git, and does happen to upload all commits off my machine immediately (although still effectively in a private fork).