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

81–90 of 97 posts

Re: Jujutsu and Radicle

#81

Post by amenhotep »

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…

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.

Re: Jujutsu and Radicle

#82

Post by mac-monet »

IshKebab wrote: post #12
mac-monet wrote: post #3

Just waiting for Jujutsu to support submodules and I can replace git completely.

I really hope they don't add submodule support. There's an opportunity to do something that works properly!

For clarity, I actually hate submodules and badly they're implemented. But its what I have to work with!

Re: Jujutsu and Radicle

#83

Post by ephimetheus »

I got into jujutsu recently for the mega merge workflow.

The only thing I’m missing now is support for git submodules, especially when working with workspaces.

This requires me to keep using git worktrees with collocated jj in each of them, which is suboptimal.

Re: Jujutsu and Radicle

#84

Post by ephimetheus »

IshKebab wrote: post #12
mac-monet wrote: post #3

Just waiting for Jujutsu to support submodules and I can replace git completely.

I really hope they don't add submodule support. There's an opportunity to do something that works properly!

I appreciate the opinion, but that precludes it from being used in repos that are not jj-first and happen to use submodules.

Re: Jujutsu and Radicle

#85

Post by sgjennings »

diarrhea wrote: post #41
stouset wrote: post #21

Earlier quoted context omitted.

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

I mostly solve this by putting a branch on the merge commit M, then the “real” change R is a child of that. The PR is targeted to merge R into M.

As the parents of M are merged, I rebase the whole stack. When M has a single parent left, I abandon M and retarget the PR to merge R into that parent.

It requires a little babysitting, but the PR shows the diff I want it to.

Re: Jujutsu and Radicle

#86

Post by roman_soldier »

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/

No, it was a clean jj init'ed repo. I think I just hadn't grokked it properly. Might give it another shot but as git works well for me right now finding the motivation/time is an issue.

Re: Jujutsu and Radicle

#87

Post by pancsta »

nchmy wrote: post #70
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…

jjui is what you're looking for. Incredible TUI https://github.com/idursun/jjui

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

Re: Jujutsu and Radicle

#88

Post by rkangel »

typpilol wrote: post #65
diarrhea wrote: post #44

Earlier quoted context omitted.

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…

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

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

Re: Jujutsu and Radicle

#89

Post by JimDabell »

prerok wrote: post #46
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 hat…

I have a similar workflow with jj.

jj will start recording all of your changes as a real commit that it constantly rewrites as you edit files. You can write the log message for it up front or later. Think of it as an index that every change automatically gets staged to, except it’s just a commit, so instead of two concepts that work differently, you just have one. And you get the benefits of real commits, so for instance you can’t accidentally lose anything you staged that isn’t committed.

When you would create a branch and then stage changes with Git, what you would do in jj is split. The changes you don’t pick end up as the next auto-updating commit, and the changes you do pick use the log message you already set when you were working on them. So if you’ve got a bunch of changes you want to record as a series of commits, you just split however many times you want.

You don’t have to think about branching while you are doing this. The HEAD of master doesn’t automatically move when you are making these changes, so the effect is that you’re working on an anonymous branch already without having to create one. You can give it a name whenever you want by setting a bookmark. Or if you decide that the changes you make need to go into two branches, then you can add two bookmarks.

For instance, if you have:

A (master) => [changes]

Then [changes] is already a commit. Suppose you realise that you have fixed a bug and added a feature, but you want these as separate pull requests. You’d split, giving the bug fix a log message:

A (master) => B (bug fix) => [changes]

Then you’d give the feature a log message:

A (master) => B (bug fix) => C (feature)

Even though we started on master and made a bunch of commits without even thinking about branches, we haven’t changed master at all. So in effect, it’s like B and C are on some anonymous branch that was transparently created for you.

Now you want to open the pull requests, so you add a bookmark for B and a bookmark for C, and push them to your remote. B and C show up as branches that you can open pull requests for.

So your workflow is basically the same as it is now, there’s just fewer moving parts for you to think about as you work, and fewer concepts for newbies to learn.

Re: Jujutsu and Radicle

#90

Post by steveklabnik »

ephimetheus wrote: post #83

I got into jujutsu recently for the mega merge workflow. The only thing I’m missing now is support for git submodules, especially when working with workspaces. This requires me to keep using git worktrees with collocated jj in each of them, which is suboptimal.

Does jj’s own workspaces not help? I don’t use submodules so I don’t know.
Post reply on HN