←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 1 comments | | HN request time: 0.001s | source
Show context
marcuskaz ◴[] No.45084298[source]
> Jujutsu is more powerful than Git. Despite the fact that it's easier to learn and more intuitive, it actually has loads of awesome capabilities for power users that completely leave Git in the dust.

Like? This isn't explained, I'm curious on why I would want to use it, but this is just an empty platitude, doesn't really give me a reason to try.

replies(7): >>45084316 #>>45084327 #>>45084439 #>>45084678 #>>45088571 #>>45092597 #>>45093098 #
senekor ◴[] No.45084439[source]
Hi, author here. Since the target audience is people with little to no Git experience, a detailed comparison would not make sense. I did simply make that claim because the weirdness of Git's UI is usually justified by saying how powerful it is. So this statement is just intended to ease the readers mind that they're not missing out on power by choosing a tool that's easier to learn.
replies(3): >>45084539 #>>45084685 #>>45087146 #
jennyholzer ◴[] No.45084539[source]
I appreciate this perspective.

IMO, the authors and evangelists of Git are essentially correct when they argue about its power.

However, I think that it's extremely difficult to gain practical experience with using Git in a high-powered, high-agency way, mostly because there are a lot of abstract concepts at play and there is no easily accessible place where these concepts can be "discovered".

Basically, Git is as good as it's cracked up to be, but only if you're an expert.

If you're interested in becoming a Git expert, I cannot recommend Emacs Magit strongly enough.

If not, I think Jujutsu could be an quicker road to a high-agency version control workflow. It's at least worth considering. I feel confident that Jujutsu can succeed, in particular because of Git's harsh difficulty curve.

replies(3): >>45084724 #>>45087011 #>>45088109 #
senekor ◴[] No.45084724[source]
Thanks, but I consider myself a Git expert already :-) I read the Pro Git book cover to cover. I have a gluten-free, artisanal, free-range git config that I've grown and cared for over years. single character aliases all the important commands, "log all graph oneline", "commit amend no-edit", interactive rebase (ofc. with autosquash, autostash, updaterefs and rebasemerges), reset hard, push force-with-lease... Also: commit signing, url rewriting, conditional configs for different orgs, all that jazz. I was super productive with it and loved it.

And then Jujutsu came along and casually doubled my VCS productivity. I didn't see it coming!

replies(1): >>45085346 #
nocman ◴[] No.45085346[source]
Is there a particular pain point (or set of pain points) that you have using git which is removed when you use Jujutsu?

I am interested to know, because there seem to be a small number of people who really seem to like it, and up to this point I haven't been able to understand what it is that they are all so excited about.

replies(4): >>45085518 #>>45085779 #>>45087984 #>>45091664 #
nchmy ◴[] No.45085518[source]
for me, everything git is a pain point. But its not so much painpoints that it addresses, as it is that it just makes entirely new things dead-simple to do, especially via jjui.

"megamerges" are one such example. ive shared many links, here and in other posts

replies(1): >>45086891 #
nocman ◴[] No.45086891[source]
> for me, everything git is a pain point

Yeah, I was looking for something (or "things") specific. An "I hate everything about it" explanation doesn't really compel me to try out the alternative.

> "megamerges" are one such example. ive shared many links, here and in other posts

I read through one megamerge link you shared ( https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... ). So the argument seems to be (forgive me if I'm reading this wrong), if you have multiple versions of a single set of source files that all have differing changes, for you JuJutsu makes it easier (easier then git, that is) to merge them into the final commit you want to end up with. Is that correct?

Just trying to make sure I understand. Honestly, after reading that article I am still not feeling the need to try Jujustu out. I'm still open to being convinced, but have yet to see anything that makes me go "wow, I need to try that!".

replies(3): >>45087517 #>>45089162 #>>45097666 #
nchmy ◴[] No.45087517[source]
"multiple versions" = feature branches, possibly all in progress, probably all related. In a couple seconds, you can create a merge on top of all of them to join up their combined functionality/changes, work on top of that ON ALL OF THEM AT ONCE, and then squash all the relevant changes into the respective PRs that others (who are just using git) can review and merge into main.

At this point A LOT has been written in this and other threads, as well as lots of essays and tutorials about how jj just completely transforms your workflow. If you're curious, you'll seek it out. If not, that's fine as well.

replies(1): >>45088708 #
typpilol ◴[] No.45088708[source]
What does the history look like then? Just a single merge from a ton of branches or?
replies(1): >>45089169 #
1. KingMob ◴[] No.45089169[source]
The parent is describing the megamerge pattern, which is a way to work on multiple branches at once.

You don't have to do that, and you rarely push it to others. History looks the same as git, usually, although I end up rebasing more than I ever did in git, since it's easier and safer.