Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu and Radicle

radicle.xyz

Post reply on HN
Print view View original

41–50 of 97 posts

Re: Jujutsu and Radicle

#41

Post by diarrhea »

stouset wrote: post #21
vlovich123 wrote: post #14

Earlier quoted context omitted.

And do downstream PRs show just what changed or is the merge target against main which then just keeps accumulating differences? This is one of the strengths I appreciate about graphite which is that the PRs are always on the preceding branch but it knows that when you go to merge it should actually really retarget and merge against main.

Github and GitLab both allow you to specify a merge target other than main and only show you the differences from the target. If that target is merged into main, they're retargeted to main. There is definitely room for an improved forge experience that takes advantage of the additional powers of jj, but it's no worse an experience using them today than it is with git.

One problem remains: jj makes it a breeze to parallelize work, but descendant changes will then end up with multiple parents. But PRs cannot target multiple target branches at once - so you cannot point them at both at once.

cf. https://jj-vcs.github.io/jj/latest/cli-reference/#jj-paralle...

Re: Jujutsu and Radicle

#42

Post by sestep »

JimDabell wrote: post #7

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.

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?

Re: Jujutsu and Radicle

#43

Post by diarrhea »

landr0id wrote: post #39
roman_soldier wrote: post #16

I tried Jujutsu on a simple repo and it ended up a mess I couldn't fix. Never had that with git. Might be my lack of knowledge but it shouldn't allow this.

Did you reach out to `git` commands to make changes to the repo? If you use jj in a colocated repo you should _only_ use jj to manage the repo to ensure it's kept in-sync with jj's data. If you messed up with jj commands, you can use the op log to fix https://jj-vcs.github.io/jj/latest/operation-log/

In colocated repos, running both git and jj commands is supported. I use it in release workflows which require git tags, which jj does not support creating. However, jj will pick up ("import") on git-created tags just fine afterwards.

AFAIK, jj runs "import" before and "export" (to git) after every invocation. That means it always has a consistent view.

jj can also handle concurrent edits by itself, think in a repo shared across a network. That said, I wouldn't think concurrent git commands are safe.

Re: Jujutsu and Radicle

#44

Post by diarrhea »

JimDabell wrote: post #7

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.

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.

Re: Jujutsu and Radicle

#45

Post by stouset »

sestep wrote: post #42
JimDabell wrote: post #7

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.

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 cu…

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.

Re: Jujutsu and Radicle

#46

Post by prerok »

wirybeige wrote: post #5

I think this is the first blog on JJ that has made me want to use it. The flow seems like it could be quite a bit better than git

Ok, so I have to admit I started skimming soon, because after explanation of `jj new`, I thought this is just `git commit --allow-empty`. Oh, and you can specify the message! Add `-m` and you are done.

Then it's a series of either git ammends or `git checkout -b` etc.

Now, since there is so much high praise in this comment and sibling comments, what am I really missing? From the post it just seems like the person hates branches for an unspecified reason.

Here's my workflow, of the past 15 years:

- git checkout main - git pull

Do some changes. Do some more changes. Now:

- git checkout -b - git status - gvim into every file and then :Gvdiffsplit, select what I want to stage for each file - git push # open PR if I think it's ready

For the remaining changes not in the commit, I either create a separate commit, or discard.

An honest question of curiosity, how does jj improve this workflow?

Re: Jujutsu and Radicle

#47

Post by gpm »

stouset wrote: post #45
sestep wrote: post #42

Earlier quoted context omitted.

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 cu…

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…

> 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.

Re: Jujutsu and Radicle

#48

Post by sestep »

gpm wrote: post #47
stouset wrote: post #45

Earlier quoted context omitted.

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…

> 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.

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.

Re: Jujutsu and Radicle

#49

Post by IshKebab »

stouset wrote: post #24
IshKebab wrote: post #13

Earlier quoted context omitted.

I dunno, I've tried it and I think I will stick with Git for a while longer at least. I really don't like the fact that it automatically commits changes in the working tree. Apparently you can turn it off but.. yeah I dunno. I may change my mind. Especially if they provide a less shit alternative to submodules and LFS. (And I agree this guy is just being contrarian - jj definitely does fix some Git annoyances.)

This was the thing that stopped me from giving jj a shot for the longest time, but it turned out to be a complete non-issue. Definitely don't turn it off! The "aha" moment you might be missing is that you should consider your latest revision to just be the staging area. `jj commit -i` (shorthand for `jj describe; jj split -i`) is effectively `git add -i; git commit`. If you're worried about accidentally pushing unfin…

Say I check out a branch (or bookmark or whatever). I compile it. Some stuff doesn't work. I add some debug printfs. Compile it again. Ok I'm done now.

In git I can just revert all the changes and I haven't modified anything important. In `jj` won't I have actually added all of those debug printfs to the top commit of that branch? Now I have to manually revert the edit?

As I understand it, the answer is "aha, but you just have to remember to `jj new` before you do any edits. The problem is I'm very sure I will constantly forget to do that. I guess you could say Git is opt-in to modifying commits whereas jj is opt-out, and I think I prefer opt-in.

I have very little jj experience but does that sound accurate? (Genuine question; I would love something better than Git.)

Re: Jujutsu and Radicle

#50

Post by theusus »

I used jj for a while and it was so problematic and seemed like nothing added value as compared to git. And now in the world of LLMs it is more difficult to switch to jj.
Post reply on HN