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

31–40 of 97 posts

Re: Jujutsu and Radicle

#31

Post by nixosbestos »

homebrewer wrote: post #19
do_not_redeem wrote: post #11

Earlier quoted context omitted.

Some people just enjoy being contrarian. I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.

You're reading an extremely biased sample of experiences. It's probably the opposite: 90% haven't tried it, 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it. For an advanced git user, it doesn't offer all that much. I used it for a couple of weeks and can't say that it saved me any time or any amount of work; it was either zero, or so close to zero that I wasn't abl…

Wow, just wow.

>For an advanced git user, it doesn't offer all that much.

arrogant, and completely absurdly wrong. I've used Git for 20 years. `jj` the single best improvement to my development workflow in... well, since adopting Git.

> I used it for a couple of weeks and can't say that it saved me any time or any amount of work

I would bet 5 figures that's a lie.

> When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.

So despite all this chest puffing, an appeal to authority would tip the scales for you?

Re: Jujutsu and Radicle

#32

Post by nothrabannosir »

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.

By any chance did you manage to get branch protection rules working neatly in this paradigm? Ideally I’d like any CI to be re-run as necessary and the branch to be automatically merged if review was approved and its base became master, but I never got a completely hands free setup working. Maybe a skill issue though.

Basically if I have five stacked PRs, and the newest four get an approval, I want everything to stay in place no merges. Then when the base (oldest) PR gets approved, I’d like the PRs to all get merged, separately , one after the other, without further interaction from me.

Does GitHub’s merge queue implementation support that?

Re: Jujutsu and Radicle

#33

Post by mrbonner »

frizlab wrote: post #8

Yup. Still 0 incentive to try jj. I’m still very much convinced most of the problems solved by jj either do not exist or are already solved by recent features of git. It’s good alternatives of popular tools exist but git would not be my first bet as a tool that needs fixing…

“You miss 100% of the shots you didn’t take” - Michael Scott.

Re: Jujutsu and Radicle

#34

Post by gpm »

hju22_-3 wrote: post #30
nrclark wrote: post #27

Earlier quoted context omitted.

I feel like submodules are one of Git's most misused features. They're intended as a method of pinning read-only upstream Git dependencies. And when used for that purpose, they're good at what they do. I think that people mostly get a bad taste in their mouths because they try to use submodules for building multi-repo workspaces where a developer might need to commit in some/all of the repos. They're a bad fit for th…

Do you know of something that's good for what people tend to misuse Git submodules for? A multi-repo workspace thingamajig.

I think what I'd like for that is a mono-repo with better support for subsetting instead of a multi-repo with better support for unioning.

I understand that Google (and may some of the other fangs) have tooling like that internally - but I haven't had the pleasure of using it.

Re: Jujutsu and Radicle

#35

Post by stouset »

nothrabannosir wrote: post #32
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.

By any chance did you manage to get branch protection rules working neatly in this paradigm? Ideally I’d like any CI to be re-run as necessary and the branch to be automatically merged if review was approved and its base became master, but I never got a completely hands free setup working. Maybe a skill issue though. Basically if I have five stacked PRs, and the newest four get an approval, I want everything to stay…

Gitlab’s does when you have merge queues set up. I’m not sure about GitHub, we didn’t have that kind of setup at the last place I worked.

Re: Jujutsu and Radicle

#36

Post by shayief »

vlovich123 wrote: post #14
watusername wrote: post #9

Earlier quoted context omitted.

From git's perspective, jj bookmarks are just regular git branches, so you can just do `jj git push` and open a PR as usual. However, unlike git, jj bookmarks are pinned to change IDs instead of immutable commit SHA-1s. This means that stacked PRs just work: Change something in the pr-1 bookmark, and all dependent bookmarks (pr-2, pr-3, ...) are automatically updated. A `jj git push --tracked` later and everything is…

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.

Gitpatch author here.

Gitpatch attempts to build a Git hosting with native support for patches and commit-based review system, where each commit is its own patch. It's also smart to handle force pushes and can update or reorder patches as needed.

Re: Jujutsu and Radicle

#37

Post by stouset »

latexr wrote: post #28
do_not_redeem wrote: post #11

Earlier quoted context omitted.

Some people just enjoy being contrarian. I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.

> 0% tried it but decided not to switch. It’s trivial to prove that’s not true. Just look at the last popular Jujutsu post on HN. https://news.ycombinator.com/item?id=44643984 https://news.ycombinator.com/item?id=44643763 https://news.ycombinator.com/item?id=44646902 https://news.ycombinator.com/item?id=44645769 https://news.ycombinator.com/item?id=44662803 https://news.ycombinator.com/item?id=44644040 And those are…

To be fair, I more or less invited these responses by bringing it up. Organically, complaints are very rare.

Obviously not everyone who tries something is going to switch, even if you take as an axiom that the other thing is objectively better. But I still think it’s notable that—without explicitly prompting that type of response—so few people seem to have negative experiences with jj given how tribal and passionate engineers tend to be over tooling.

Re: Jujutsu and Radicle

#38

Post by 1718627440 »

do_not_redeem wrote: post #11
magnio wrote: post #10

Earlier quoted context omitted.

Why say yup to disagree with the premise of the article?

Some people just enjoy being contrarian. I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.

> Some people just enjoy being contrarian.

I have recently posted some critical questions. I didn't do that because I "enjoy being contrarian" (rather me enjoying a discussion). I did that to flesh out, what the benefits of JJ are. I think VCSs are interesting, I think Git has some issues, but in my opinion most problems are caused by a misguided mental models, I haven't/can't tried JJ. Most things I heard were workflows that are claimed are not possible in Git, but are possible and most-times only a few commands. There are other design choices which I disagree with and which might bother me.

("haven't/can't tried JJ" meaning I enjoy running a stable distro, but wouldn't mind compiling it myself. But Rust and Rust software is a fast moving target, so it is a hassle to deal with if you aren't invested in it's ecosystem. Also it violates the GNU standard, which makes it unfriendly for endusers, but this seams to be the norm nowadays.)

Re: Jujutsu and Radicle

#39

Post by landr0id »

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/

Re: Jujutsu and Radicle

#40

Post by stouset »

nixosbestos wrote: post #31
homebrewer wrote: post #19

Earlier quoted context omitted.

You're reading an extremely biased sample of experiences. It's probably the opposite: 90% haven't tried it, 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it. For an advanced git user, it doesn't offer all that much. I used it for a couple of weeks and can't say that it saved me any time or any amount of work; it was either zero, or so close to zero that I wasn't abl…

Wow, just wow. >For an advanced git user, it doesn't offer all that much. arrogant, and completely absurdly wrong. I've used Git for 20 years. `jj` the single best improvement to my development workflow in... well, since adopting Git. > I used it for a couple of weeks and can't say that it saved me any time or any amount of work I would bet 5 figures that's a lie. > When Linus and his lieutenants switch over and reco…

There’s no need to be antagonistic. We’re all friends here :)

I am an unabashed jj evangelist and I don’t think they’re lying when they say it didn’t save them any time. Adoption costs might be small but they’re not zero. Some workflows are easy with either tool. And some people just don’t “get” it and struggle to adapt to a different mental model. That’s okay!

> So despite all this chest puffing, an appeal to authority would tip the scales for you?

I think GP was simply saying this would be a clear sign to them that if it’s mature enough to handle kernel developers’ needs, that’s a good sign it’s worth the effort to switch. It definitely would be! I can’t wait to hear if and when kernel developers start switching; it will be a huge positive indicator.

Post reply on HN