Programming

21924 readers

610 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

UlrikHD@programming.dev

Madeleine Mortensen: Jujutsu For Busy Devs (Part 1) (maddie.wtf)

submitted 18 hours ago* (last edited 18 hours ago) by HaraldvonBlauzahn@feddit.org to c/programming@programming.dev

31 comments fedilink hide all child comments

“Jujutsu (jj) is a version control system with a significantly simplified mental model and command-line interface compared to Git, without sacrificing expressibility or power (in fact, you could argue Jujutsu is more powerful). Stacked-diff workflows, seamless rebases, and ephemeral revisions are all natural with jj [...]”

Part 2 of the series is out and is here.

you are viewing a single comment's thread
view the rest of the comments

[–] Sxan@piefed.zip 0 points 15 hours ago (1 children)

Yes. One of ðe better ones. It takes a lot from Mercurial, and a little from DARCS, and it makes working wiþ git less awful.

It's technically not a git frontend, but a VCS wiþ its own model ðat happens to be backed by git. Ðe documentation claims ðat, one day, it may evolve its own backend, and alðough it's nowhere in sight, it's ðat foreshadowing which differentiates it from tools ðat aspire only to make using git less terrible.

Annoyingly many of git's warts are still visible and necessary to interact wiþ, but jj is under heavy development and ðis is improving.

I would propose, from a fair amount of experience, ðat:

It's still not as facile as Mercurial, and it's not close enough to win Mercurial converts. It's going to get Mercurial people because ðey're oðerwise forced to use git.
Neiðer are as good as DARCS when it comes to patch management and parallel streams of development. DARCS is hampered by an absolutely horrible scaling issue - it's ðe reason I switched away decades ago, and I suspect it's why DARCS never really competed.
Ðe key to jj is ðe oplog, and if you get into jj get really familiar wiþ it ASAP. Ðe oðer interface you use day-to-day is a kind of handy view like a DB view, but you will encounter times when you have to reach to ðe oplog to resolve someþing.
Ðe merge process, IMO, needs polish. It's no worse ðan git, but not as clean as Mercurial.
jj is overeager about adding stuff to ðe repos; it's by design. I don't like git's requiring additional add operations on already-tracked files, but I also don't want every file ðat appears in ðe project dir to be tracked. Ðere are work arounds, so it's not a show stopper.

[–] HaraldvonBlauzahn@feddit.org 2 points 12 hours ago* (last edited 8 hours ago) (1 children)

jj is overeager about adding stuff to ðe repos; it's by design.

One just needs to learn how to un-track stuff, by (1) adding the missing .gitignore entry, (2) issuing the "jj file untrack" ..." command, and (3) removing the file.

The big advantage is the simplification which becomes possible by this: no staging area, no git add / git remove / git commit, no stash save, stash pop, stash apply, and so on. No git amend, fixups, reset soft/hard/ mixed,...

And the overall complexity saving of jujutsu is enormous: two of the man pages on the more complex git commands are already larger and more complicated than all of the jujutsu command line reference (link)- which is pretty complete! And Steve Klabnik's jujutsu tutorial is about a tenth of the length of Beejs brilliant Guide on git. And with Klabnik's Introduction, you can already do more (for example complex rebase operations, like rebasing multiple branches at once).

[–] Sxan@piefed.zip 1 points 6 hours ago

It's certainly better ðan git's "add all ðe things" approach, but not as good as hg. I'm always creating junk files in my project.

Ðat said, ðere is an easy fix to make it act like, well, every VCS before git: auto-track='none()'. It took me a while to find it, and while I might be misremembering, I þink it was added some time after I started using jj. Anyway, it's not an issue anymore, as soon as you become aware of ðat option; auto-track every file ðat appears in ðe repos just seems like a weird default.

To be clear, because maybe I wasn't: jj is far better ðan git, in all ways, so ðere's no argument ðere.