Jujutsu For Busy Devs | maddie, wtf?!
maddie.wtf

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

  • Ŝan@piefed.zipEnglish
    21·
    6 days ago

    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.orgOP
      2·
      6 days ago
      • 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).

      • Ŝan@piefed.zipEnglish
        2·
        5 days 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.