[JimDabell]

I’ve started using Jujutsu recently and was surprised at how low friction it was to switch. If you’re like the author and keep hearing about it without giving it a shot, I suggest you just sit down and try it – it’s a lot less effort than you might expect.

[sestep]

I really like all the concepts and have only heard good things, so I tried it but wasn't able to figure out how to use it as effectively as I can use Git. Specifically, I use VS Code and do a lot of stuff with the IDE's builtin support for selecting specific parts of files to stage, and I was hoping to be able to do something similar for jj split. I asked the Jujutsu Kaizen devs on Discord and they said that isn't currently implemented. They did also mention that VisualJJ might have more what I want, but I'm reluctant to switch to JJ only to have to rely on a closed-source tool.

Are there others who've previously made heavy use of VS Code's builtin Git staging support and have successfully migrated to JJ? Anything I'm missing?

[stouset]

As far as I know right now, no editors have great built-in support. As a heavy CLI user of (previously) git and now jj, selecting changes graphically is genuinely the one thing I’m envious of. The TUI that jj uses for interactive changes, `scm-record`, is fine but not great. It gets the job done but it could be so much more.

Getting really good diff and conflict editor support into VS Code, Zed, et al is going to be a huge win when it comes.

[gpm]

> The TUI that jj uses for interactive changes, `scm-record`, is fine but not great.

The change selection TUI is one of the things that I'm happiest with in jj over the equivalent in git. It's a huge quality of life improvement over git's version.

Could it be even better? Probably... but compared to `git add -p`... it is already way better.

[sestep]

Right, but the only time I've ever used `git add -p` was just to try it out years ago and be like "yep that sucks" and go back to using Magit (and then later VS Code). Those are my actual baselines.

[gpm]

Totally fair, I stubbornly used `git add -p` anyways because the terminal is where I want that tool to live, but I entirely understand why other people have different habits here.

[nchmy]

jjui is what you're looking for. Incredible TUI

https://github.com/idursun/jjui

[pancsta]

Unfortunately its written in a simplistic TUI framework. Will never scale, pass.

[i_dursun]

> Will never scale

won't scale to what exactly?

[stouset]

I use jjui, but it still punts to scm-record for interactive hunk selection.

[amenhotep]

JJ can be configured to use meld for what I think you mean, although I'm not quite au fait enough with version control to be sure. Not as frictionless as being able to do it in VSC but meld is nice and open source.

[diarrhea]

One of my favorite features of jj is file watching. Once set up, jj will snapshot the repo on every filesystem event. This means on every file save, you get a git commit! It provides arbitrarily fine-grained commit history, and works across all tools (not just your IDE). I set it up in the config and it has "just worked" ever since.

The result is that `jj evolog -p` will show detailed history of your actions. But all but the most recent commit are hidden, so neatly tucked away behind the same change as usual.

Another favorite is git no longer yelling at me and having meltdowns about switching branches - "files would be overwritten, please stash". This never happens in jj, by design. It's nicer than "auto-stash" options of recent git versions.

[typpilol]

Wouldn't you end up with like 1 million commits in a decent size projects really quickly?

[rkangel]

It's not a commit per change - all changes made since the last commit are in a new commit. You then usually do one of two things:

- Decide your changes are perfect, so add a commit message to this one and then create a new one on to to carry on

- Decide you only want some of them so use `jj split -i` to select which ones you want and then it creates two commits - the stuff you want in a new named commit, and the stuff you didn't in a new working copy commit. This is the JJ workflow equivalent to `git add -p` adding to the staging area then committing

[mtndew4brkfst]

It is, however, a commit object per change because of how jj tracks the evolution of commits. Those intermediate/ephemeral commits will not be able to be GC'd from git object storage until they are either abandoned in jj or are removed from the jj op log. The latter of which AFAIK does not happen automatically, not even on a time/age basis.

I am an extremely fervent believer in jj and use it exclusively since December '24, but I think it's useful to be accurate as possible for these kinds of trade offs. I don't use watchman snapshots specifically because of this downside.

[steveklabnik]

These are entirely local, and can be GC’d.

[typpilol]

Oh I understand. I guess it works just like the local history plugin for vscode. It makes a snapshot of every file edit as well.

Thanks